区块链版本兼容性验证方法及装置、电子设备与流程

1.本说明书一个或多个实施例涉及区块链技术领域，尤其涉及一种区块链版本兼容性验证方法及装置、电子设备。


背景技术：

2.区块链技术，也被称之为分布式账本技术，是一种由若干台计算设备共同参与“记账”，共同维护一份完整的分布式数据库的新兴技术。由于区块链技术具有去中心化、公开透明、每台计算设备可以参与数据库记录、并且各计算设备之间可以快速的进行数据同步的特性，使得区块链技术已在众多的领域中广泛的进行应用。


技术实现要素：

3.本说明书实施例提供的一种提高信息安全的方法及装置、电子设备。
4.根据本说明书实施例的第一方面，提供一种区块链版本兼容性验证方法，所述方法应用于所述区块链中的目标节点设备；其中，所述区块链支持进行软件版本升级；所述方法包括：
5.获取待验证的历史区块，并从所述历史区块中读取待验证的交易；
6.基于所述区块链支持的第一软件版本执行所述交易，得到第一交易执行结果；以及，基于所述区块链支持的第二软件版本执行所述交易，得到第二交易执行结果；
7.将所述第一交易执行结果与所述第二交易执行结果进行匹配，并基于所述匹配的结果以确定所述第一软件版本与所述第二软件版本是否兼容。
8.可选的，在所述基于所述区块链支持的第一软件版本执行所述交易，得到第一交易执行结果；以及，基于所述区块链支持的第二软件版本执行所述交易，得到第二交易执行结果之前，还包括：
9.从所述区块链对应的历史状态数据库中，获取与所述历史区块对应的历史状态数据；其中，与所述历史区块对应的历史状态数据被设置为只读状态；
10.从与所述历史区块对应的历史状态数据中读取与所述交易相关的区块链账户对应的初始账户状态。
11.可选的，所述交易执行结果包括执行交易后生成的交易收据；
12.所述基于所述区块链支持的第一软件版本执行所述交易，得到第一交易执行结果；
13.基于所述区块链支持的第一软件版本执行所述交易，生成针对所述初始账户状态对应的更新账户状态，并基于所述初始账户状态和所述更新账户状态生成所述交易对应于所述第一软件版本的第一交易收据；
14.所述基于所述区块链支持的第二软件版本执行所述交易，得到第二交易执行结果，包括：
15.基于所述区块链支持的第二软件版本执行所述交易，生成针对所述初始账户状态
对应的更新账户状态，并基于所述初始账户状态和所述更新账户状态生成所述交易对应于所述第二软件版本的第二交易收据。
16.可选的，所述目标节点设备搭载了用于记录交易执行结果的服务端口；
17.在所述将所述第一交易执行结果与所述第二交易执行结果进行匹配之前，还包括：
18.调用所述服务端口，在本地存储生成的所述第一交易收据和所述第二交易收据。
19.可选的，所述将所述第一交易执行结果与所述第二交易执行结果进行匹配，并基于所述匹配的结果以确定所述第一软件版本与所述第二软件版本是否兼容，包括：
20.读取所述服务端口记录的所述第一交易收据和所述第二交易收据；
21.将读取到的所述第一交易收据和所述第二交易收据进行匹配；
22.如果所述第一交易收据与所述第二交易收据匹配，确定所述第一软件版本与所述第二软件版本兼容；反之，确定所述第一软件版本与所述第二软件版本不兼容。
23.可选的，所述获取待验证的历史区块，包括：
24.获取用户指定的待验证的历史区块对应的区块号区间；
25.从所述区块号区间中读取待验证的历史区块的区块号，并在本地维护的所述区块链的区块数据中读取与所述区块号对应的历史区块。
26.可选的，所述本地维护的所述区块链的区块数据为预先拷贝至所述目标节点设备的区块数据。
27.可选的，所述区块链支持进行软件版本的灰度升级；所述第一软件版本包括最新软件版本；所述第二软件版本包括将所述区块链中的部分节点设备支持的软件版本灰度升级为所述最新软件版本之前，所述部分节点设备支持的历史软件版本。
28.可选的，在所述获取待验证的历史区块，并从所述历史区块中读取待验证的交易之前，还包括：
29.响应于所述区块链中的部分节点设备支持的软件版本灰度升级为所述最新软件版本，获取待验证的历史区块，并从所述历史区块中读取待验证的交易。
30.可选的，所述方法还包括：
31.如果确定所述最新软件版本与所述历史软件版本兼容，向所述区块链对应的服务平台发送升级指示，以触发所述服务平台将所述部分节点设备支持的软件版本由所述历史软件版本升级为所述最新软件版本。
32.可选的，所述服务平台包括bass平台。
33.可选的，所述目标节点设备包括所述区块链中预设的不参与共识的非共识节点。
34.根据本说明书实施例的第二方面，提供一种区块链版本兼容性验证装置，所述装置应用于所述区块链中的目标节点设备；其中，所述区块链支持进行软件版本升级；所述装置包括：
35.获取单元，获取待验证的历史区块，并从所述历史区块中读取待验证的交易；
36.执行单元，基于所述区块链支持的第一软件版本执行所述交易，得到第一交易执行结果；以及，基于所述区块链支持的第二软件版本执行所述交易，得到第二交易执行结果；
37.验证单元，将所述第一交易执行结果与所述第二交易执行结果进行匹配，并基于
所述匹配的结果以确定所述第一软件版本与所述第二软件版本是否兼容。
38.可选的，在所述执行单元之前，还包括：
39.数据获取子单元，从所述区块链对应的历史状态数据库中，获取与所述历史区块对应的历史状态数据；其中，与所述历史区块对应的历史状态数据被设置为只读状态；从与所述历史区块对应的历史状态数据中读取与所述交易相关的区块链账户对应的初始账户状态。
40.可选的，所述交易执行结果包括执行交易后生成的交易收据；
41.所述执行单元，进一步包括：
42.第一执行子单元，基于所述区块链支持的第一软件版本执行所述交易，生成针对所述初始账户状态对应的更新账户状态，并基于所述初始账户状态和所述更新账户状态生成所述交易对应于所述第一软件版本的第一交易收据；
43.第二执行子单元，基于所述区块链支持的第二软件版本执行所述交易，生成针对所述初始账户状态对应的更新账户状态，并基于所述初始账户状态和所述更新账户状态生成所述交易对应于所述第二软件版本的第二交易收据。
44.可选的，所述目标节点设备搭载了用于记录交易执行结果的服务端口；
45.在所述验证单元之前，还包括：
46.调用单元，调用所述服务端口，在本地存储生成的所述第一交易收据和所述第二交易收据。
47.可选的，所述验证单元，进一步包括：
48.读取子单元，读取所述服务端口记录的所述第一交易收据和所述第二交易收据；
49.匹配子单元，将读取到的所述第一交易收据和所述第二交易收据进行匹配；
50.确定子单元，如果所述第一交易收据与所述第二交易收据匹配，确定所述第一软件版本与所述第二软件版本兼容；反之，确定所述第一软件版本与所述第二软件版本不兼容。
51.可选的，所述获取单元，进一步包括：获取用户指定的待验证的历史区块对应的区块号区间，从所述区块号区间中读取待验证的历史区块的区块号，并在本地维护的所述区块链的区块数据中读取与所述区块号对应的历史区块。
52.可选的，所述本地维护的所述区块链的区块数据为预先拷贝至所述目标节点设备的区块数据。
53.可选的，所述区块链支持进行软件版本的灰度升级；所述第一软件版本包括最新软件版本；所述第二软件版本包括将所述区块链中的部分节点设备支持的软件版本灰度升级为所述最新软件版本之前，所述部分节点设备支持的历史软件版本。
54.可选的，在所述获取单元之前，还包括：
55.响应单元，响应于所述区块链中的部分节点设备支持的软件版本灰度升级为所述最新软件版本，获取待验证的历史区块，并从所述历史区块中读取待验证的交易。
56.可选的，所述装置还包括：
57.处理单元，如果确定所述最新软件版本与所述历史软件版本兼容，向所述区块链对应的服务平台发送升级指示，以触发所述服务平台将所述部分节点设备支持的软件版本由所述历史软件版本升级为所述最新软件版本。
58.可选的，所述服务平台包括bass平台。
59.可选的，所述目标节点设备包括所述区块链中预设的不参与共识的非共识节点。
60.根据本说明书实施例的第三方面，提供一种电子设备，包括：
61.处理器；
62.用于存储处理器可执行指令的存储器；
63.其中，所述处理器被配置为上述任一项区块链版本兼容性验证方法。
64.本说明书实施例，提供了一种区块链版本兼容性验证方案，由区块链支持的第一软件版本和第二软件版本分别执行历史区块中交易，通过比较两者的交易执行结果，以验证第一软件版本与所述第二软件版本是否兼容。
附图说明
65.图1是一示例性实施例提供的一种区块链版本兼容性验证方法的流程图；
66.图2是一示例性实施例提供的一种电子设备的结构示意图；
67.图3是一示例性实施例提供的一种区块链版本兼容性验证装置的框图。
具体实施方式
68.这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实现方式并不代表与本说明书一个或多个实施例相一致的所有实现方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书一个或多个实施例的一些方面相一致的装置和方法的例子。
69.需要说明的是：在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中，其方法所包括的步骤可以比本说明书所描述的更多或更少。此外，本说明书中所描述的单个步骤，在其他实施例中可能被分解为多个步骤进行描述；而本说明书中所描述的多个步骤，在其他实施例中也可能被合并为单个步骤进行描述。
70.区块链一般被划分为三种类型：公有链(public blockchain)，私有链(private blockchain)和联盟链(consortium blockchain)。此外，还可以有上述多种类型的结合，比如私有链+联盟链、联盟链+公有链等。
71.其中，去中心化程度最高的是公有链。加入公有链的参与者(也可称为区块链中的节点)可以读取链上的数据记录、参与交易、以及竞争新区块的记账权等。而且，各节点可自由加入或者退出网络，并进行相关操作。
72.私有链则相反，该网络的写入权限由某个组织或者机构控制，数据读取权限受组织规定。简单来说，私有链可以为一个弱中心化系统，其对节点具有严格限制且节点数量较少。这种类型的区块链更适合于特定机构内部使用。
73.联盟链则是介于公有链以及私有链之间的区块链，可实现“部分去中心化”。联盟链中各个节点通常有与之相对应的实体机构或者组织；节点通过授权加入网络并组成利益相关联盟，共同维护区块链运行。
74.基于区块链的基本特性，区块链通常是由若干个区块构成。在这些区块中分别记
录有与该区块的创建时刻对应的时间戳，所有的区块严格按照区块中记录的时间戳，构成一条在时间上有序的数据链条。
75.对于物理世界产生的真实数据，可以将其构建成区块链所支持的标准的交易(transaction)格式，然后发布至区块链，由区块链中的节点设备对收到的交易进行共识处理，并在达成共识后，由区块链中作为记账节点的节点设备，将这笔交易打包进区块，在区块链中进行持久化存证。
76.一般的，本轮的记账节点可以将接收到的交易打包以生成候选区块，并将生成的候选区块或者该候选区块的区块头发送至其它节点设备进行共识验证。如果其它节点设备接收到候选区块或者该候选区块的区块头后，经验证没有问题，可以将该候选区块作为最新区块追加到原有的区块链末尾，从而完成区块链的记账过程。其它节点验证记账节点发来的新的区块或区块头的过程中，也可以执行该区块中的包含的交易。
77.在区块链领域，有一个重要的概念就是账户(account)；通常将账户划分为外部账户和合约账户两类；外部账户就是由用户直接控制的账户，也称之为用户账户；而合约账户则是由用户通过外部账户创建的，包含合约代码的账户(即智能合约)。
78.当然，对于一些账户模型的区块链(比如蚂蚁区块链)，还可以对区块链支持的账户类型，进行进一步的扩展，在本说明书中不进行特别限定。
79.对于区块链中的账户而言，通常会通过一个结构体，来维护账户的账户状态。当区块中的交易被执行后，区块链中与该交易相关的账户的状态通常也会发生变化。
80.一般的，账户的结构体通常包括balance，nonce，code和storage等字段。其中：
81.balance字段，用于维护账户目前的账户余额；
82.nonce字段，用于维护该账户的交易次数；它是用于保障每笔交易能且只能被处理一次的计数器，有效避免重放攻击；
83.code字段，用于维护该账户的合约代码；在实际应用中，code字段中通常仅维护合约代码的hash值；因而，code字段通常也称之为codehash字段。
84.storage字段，用于维护该账户的存储内容(默认字段值为空)；对于合约账户而言，通常会分配一个独立的存储空间，用以存储该合约账户的存储内容；该独立的存储空间通常称之为该合约账户的账户存储。合约账户的存储内容通常会构建成mpt(merkle patricia trie)树的数据结构存储在上述独立的存储空间之中；其中，基于合约账户的存储内容构建成的mpt树，通常也称之为storage树。而storage字段通常仅维护该storage树的根节点；因此，storage字段通常也称之为storageroot字段。
85.其中，对于外部账户而言，以上示出的code字段和storage字段的字段值均为空值。
86.对于大多数区块链模型，通常都会使用merkle树；或者，基于merkle树的数据结构，来存储和维护数据。例如使用mpt树(一种merkle树变种)作为数据组织形式，用来组织和管理账户状态、交易信息等重要数据。
87.对区块链中需要存储和维护的数据，设计了三棵mpt树，分别是mpt状态树、mpt交易树和mpt收据树。其中，除了以上三棵mpt树以外，实际上还存在一棵基于合约账户的存储内容构建的storage树。
88.mpt状态树，是由区块链中所有账户的账户状态(state)数据组织成的mpt树；mpt
交易树，是由区块链中的交易(transaction)数据组织成的mpt树；mpt收据树，是区块中的交易在执行完毕后生成的与每笔交易对应的交易(receipt)收据组织成的mpt树。以上示出的mpt状态树、mpt交易树和mpt收据树的根节点的hash值，最终都会被添加至对应区块的区块头中。
89.其中，mpt交易树和mpt收据树均与区块相对应，即每一个区块都有自己的mpt交易树和mpt收据树。而mpt状态树是一个全局的mpt树，并不与某一个特定的区块相对应，而是涵盖了区块链中所有账户的账户状态数据。
90.对于组织成的mpt交易树、mpt收据树和mpt状态树，最终都会在采用多级数据存储结构的key-value型数据库(比如，leveldb)中进行存储。
91.而采用多级数据存储结构的上述数据库，通常采用多级数据存储的结构，可以被划分为n级数据存储；例如，各级数据存储可以依次设为l0，l1，l2，l3....l(n-1)；对于上述数据库中的各级数据存储而言，等级编号越小通常级别越高；例如，l0存储的是最新的若干区块的数据，l1存储的是次新的若干区块的数据，以此类推。
92.其中，各级数据存储对应的存储介质的读写性能，通常也可以存在性能差异；例如，级别高(即等级编号较小的)的数据存储对应的存储介质的读写性能，可以高于级别低的数据存储对应的存储介质的读写性能。在实际应用中，级别高的数据存储，可以使用存储成本较高，存储性能较优的存储介质；而级别低的数据存储，可以使用单位成本低，且容量较大的存储介质。
93.在实际应用中，随着区块链的区块号的增长(也称之为区块高度)，在数据库中存储的数据，会包含很多历史数据；而且，区块号越小的区块中的数据越久远，越不重要。因此，为了降低整体的存储成本，通常可以对不同区块高度的数据进行“区别对待”；例如，可以将区块号较小的区块中的数据，存储至成本较低的存储介质上；而将区块号较大的区块中的数据，存储在成本较高的存储介质上。
94.需要说明的是，区块链每产生一个最新区块，则在该最新区块中的交易被执行之后，区块链中这些被执行交易的相关账户(可以是外部账户也可以是合约账户)的账户状态，通常也会随之发生变化；
95.例如，当区块中的一笔“转账交易”执行完毕后，与该“转账交易”相关的转出方账户和转入方账户的余额(即这些账户的balance字段的字段值)，通常也会随之发生变化。
96.而节点设备在区块链产生的最新区块中的交易执行完毕后，由于当前区块链中的账户状态发生了变化，因此节点设备需要根据区块链中所有账户当前的账户状态数据，来构建mpt状态树，用于维护区块链中所有账户的最新状态。
97.也即，每当区块链中产生一个最新区块，并且该最新区块中的交易执行完毕后，导致区块链中的账户状态发生了变化，节点设备都需要基于区块链中所有账户最新的账户状态数据，重新构建一棵mpt状态树。换句话说，区块链中每一个区块，都有一个与之对应的mpt状态树；该mpt状态树，维护了在该区块中的交易在执行完毕后，区块链中所有账户最新的账户状态。
98.以区块链的账户状态数据组织成的mpt状态树为例进行说明。
99.mpt树，是一种较为传统的经过改良的merkle树变种，其融合了merkle树和trie字典树(也称之为前缀树)两种树形结构的优点。
100.在mpt树中通常包括三种数据节点，分别为叶子节点(leaf node)，扩展节点(extension node)和分支节点(branch node)。
101.扩展节点，表示为[key，value]的一个键值对，其中key是种特殊的十六进制编码字符，表示账户地址的共享字符前缀；其中，所述共享字符前缀，是指多有区块链账户地址所具有的相同的一个或者多个字符组成的前缀；value是其它节点的hash值(hash指针)，也就是说可以通过hash指针链接到其它节点。
[0102]
分支节点，包含17个元素，前16个元素对应着key中的16个可能的十六进制字符，一个字符对应一个nibble(半字节)，分别表示一个账户地址的共享字符前缀(长度为一个字符)。其中，如果有一个[key，value]对在这个分支节点终止，则该分支节点可以充当叶子节点的角色，最后一个元素则代表叶子节点的value值；反之，分支节点的最后一个元素，可以为空值。
[0103]
叶子节点，是表示为[key，value]的一个键值对，其中key也是种特殊的十六进制编码字符，表示账户地址的字符后缀；其中，账户地址的字符后缀和账户地址的共享字符前缀共同组成了一个完整的账户地址；所述字符后缀，是指除了账户地址的共享字符前缀以外的最后一个或者多个字符组成的后缀；value是该叶子节点对应的账户地址的状态数据(即以上示出的结构体)。
[0104]
由于在mpt树上，从根节点到一个叶子节点的搜索路径上的字符，组成一个完整的账户地址；因此，对于分支节点而言，其既可以是上述搜索路径的终止节点，也可以是上述搜索路径的中间节点。
[0105]
假设需要组织成mtp状态树的账户状态数据如下表1所示：
[0106][0107]
表1
[0108]
在表1中，账户地址是由若干16进制的字符构成的字符串。账户状态state，是由上述balance，nonce，code和storage等字段构成的结构体。
[0109]
最终按照表1中的账户状态数据组织成的mpt状态树；该mpt状态树是由4个叶子节点，2个分支节点，和2个扩展节点(其中一个扩展节点作为根节点)构成。
[0110]
prefix字段为扩展节点和叶子节点共同具有的前缀字段。该prefix字段的不同字段值可以用于表示不同的节点类型。
[0111]
例如，prefix字段的取值为0，表示包含偶数个nibbles的扩展节点；如前所述，nibble表示半字节，由4位二进制组成，一个nibble可以对应一个组成账户地址的字符。prefix字段的取值为1，表示包含奇数个nibble(s)的扩展节点；prefix字段的取值为2，表示包含偶数个nibbles的叶子节点；prefix字段的取值为3，表示包含奇数个nibble(s)的叶子节点。
[0112]
而分支节点，由于其是并列单nibble的前缀节点，因此分支节点不具有上述prefix字段。
[0113]
扩展节点中的shared nibble字段，对应该扩展节点所包含的键值对的key值，表示账户地址之间的共同字符前缀；比如，上表中的所有账户地址均具有共同的字符前缀a7。next node字段中填充下一个节点的hash值(hash指针)。
[0114]
分支节点中的16进制字符0～f字段，对应该分支节点所包含的键值对的key值；如果该分支节点为账户地址在mpt树上的搜索路径上的中间节点，则该分支节点的value字段可以为空值。0～f字段中用于填充下一个节点的hash值。
[0115]
叶子节点中的key-end，对应该叶子节点所包含的键值对的key值，表示账户地址的最后几个字符(账户地址的字符后缀)。从根节点搜索到叶子节点的搜索路径上的各个节点的key值，构成了一个完整的账户地址。该叶子节点的value字段填充账户地址对应的账户状态数据；例如，可以对上述balance，nonce，code和storage等字段构成的结构体进行编码后，填充至叶子节点的value字段。
[0116]
进一步的，mpt状态树上的node，最终也是以key-value键值对的形式存储在数据库中；
[0117]
其中，当mpt状态树上的node在数据库中进行存储时，mpt状态树上的node的键值对中的key，可以为node所包含的数据内容的hash值；mpt状态树上的node的键值对中的value，为node所包含的数据内容。
[0118]
也即，在将mpt状态树上的node存储至数据库时，可以计算该node所包含的数据内容的hash值(即对node整体进行hash计算)，并将计算出的hash值作为key，将该node所包含的数据内容作为value，生成key-value键值对；然后，将生成的key-value键值对存储至数据库中。
[0119]
由于mpt状态树上的node，是以node所包含的数据内容的hash值为key，node所包含的数据内容为value进行存储；因此，在需要查询mpt状态树上的node时，通常可以基于node所包含的数据内容的hash值作为key来进行内容寻址。
[0120]
在实际应用中，不论是公有链、私有链还是联盟链，都可能提供智能合约(smart contract)的功能。区块链上的智能合约是在区块链上可以被交易触发执行的合约。智能合约可以通过代码的形式定义。
[0121]
智能合约创建后，区块链上出现一个与该智能合约对应的合约账户，并拥有一个特定的地址；合约代码(code)和账户存储(storage)将保存在该合约账户的账户存储中。智能合约的行为由合约代码控制，而智能合约的账户存储则保存了合约的状态。换句话说，智能合约使得区块链上产生包含合约代码和账户存储的虚拟账户。
[0122]
前述提到，包含创建智能合约的交易的data字段保存的可以是该智能合约的字节码。字节码由一连串的字节组成，每一字节可以标识一个操作。基于开发效率、可读性等多方面考虑，开发者可以不直接书写字节码，而是选择一门高级语言编写智能合约代码。例如，高级语言可以采用诸如solidity、serpent、lll语言等。对于采用高级语言编写的智能合约代码，可以经过编译器编译，生成可以部署到区块链上的字节码。
[0123]
以solidity语言为例，用其编写的合约代码与面向对象编程语言中的类(class)很相似，在一个合约中可以声明多种成员，包括状态变量、函数、函数修改器、事件等。状态变量是永久存储在智能合约的账户存储(storage)字段中的值，用于保存合约的状态。
[0124]
在现有区块链技术中，区块链的软件版本存在需要升级的需求。每次区块链的版
本升级都需要发布一个新版本的区块链，用于替换旧版本的区块链。
[0125]
由于每次区块链的版本升级都是直接将旧版本替换为新版本，中间没有过度期，替换后直接影响区块链的所有用户。如果新旧版本的区块链存在不兼容的问题，那么使用新版本的区块链来处理的交易就会出现错误。
[0126]
因此，如何提前发现新版本与旧版本区块链之间的兼容性问题称为业内亟待解决的问题。
[0127]
本说明书针对上述问题，提出了一种区块链版本兼容性验证方案。通过该方案可以在新版本正式使用之前预先验证新老版本是否存在兼容性问题。
[0128]
请参见图1，图1是一示例性实施例提供的一种区块链版本兼容性验证方法的流程图。所述方法应用于所述区块链中的目标节点设备；其中，所述区块链支持进行软件版本升级。在接收到区块链的最新软件版本，不用马上进行区块链的版本升级，而是可以执行以下步骤：
[0129]
步骤210：获取待验证的历史区块，并从所述历史区块中读取待验证的交易。
[0130]
目标节点设备首先可以获取待验证的历史区块，并从所述历史区块中读取待验证的交易。
[0131]
其中，所述历史区块可以是预设的历史区块，也可以是用户指定的历史区块。
[0132]
以预设的历史区块为例，可以从本地维护的所述区块链的区块数据中读取最新一个的历史区块。
[0133]
以用户指定的历史区块为例，所述获取待验证的历史区块，可以包括：
[0134]
获取用户指定的待验证的历史区块对应的区块号区间；
[0135]
从所述区块号区间中读取待验证的历史区块的区块号，并在本地维护的所述区块链的区块数据中读取与所述区块号对应的历史区块。
[0136]
其中，所述本地维护的所述区块链的区块数据为预先拷贝至所述目标节点设备的区块数据。为了保证目标节点设备可以正确获取到的历史区块，需要将区块链中最新的区块数据同步到目标节点设备的本地。
[0137]
在一示例性的实施例中，所述目标节点设备包括所述区块链中预设的不参与共识的非共识节点。
[0138]
一般的，区块链中的节点可以分为共识节点和非共识节点，所述非共识节点是指不进行共识的区块链节点。其中，共识节点一般用于处理需要进行共识的交易；而非共识节点可以用于处理无需共识的交易。
[0139]
而本实施例中第一软件版本和第二软件版本执行的交易为历史区块中的历史交易，这列交易并不需要共识，因此可以将不参与共识的非共识节点作为目标节点设备。如此，不会因为占用共识节点的资源而影响正常交易。
[0140]
类似的，在有的实施例中，为了不占用区块链中现有的共识节点和非共识节点资源，还可以在所述区块链上新增一个用于验证软件版本兼容性的非共识节点。
[0141]
步骤220：基于所述区块链支持的第一软件版本执行所述交易，得到第一交易执行结果；以及，基于所述区块链支持的第二软件版本执行所述交易，得到第二交易执行结果；
[0142]
其中，所述第一软件版本可以包括最新软件版本；所述第二软件版本可以包括将所述区块链中的部分节点设备支持的软件版本灰度升级为所述最新软件版本之前，所述部
分节点设备支持的历史软件版本。
[0143]
目标节点设备在读取到待验证的交易后，可以分别基于最新软件版本和历史软件版本执行相同的待验证的交易。
[0144]
在一示例性的实施例中，在所述步骤220之前，所述方法还可以包括：
[0145]
从所述区块链对应的历史状态数据库中，获取与所述历史区块对应的历史状态数据；其中，与所述历史区块对应的历史状态数据被设置为只读状态；
[0146]
从与所述历史区块对应的历史状态数据中读取与所述交易相关的区块链账户对应的初始账户状态。
[0147]
该示例中，待验证交易被再次执行是为了验证区块链软件版本的兼容性，并非正常的交易执行，因此不管是第一软件版本还是第二软件版本执行该交易的结果都不应该记入状态数据中；不然会导致状态数据的异常。例如，假设待验证交易为账户a向账户b转账，如果允许将执行结果记入状态数据，那么账户a会真的向账户b进行转账，而实际上账户a并未发起转账，从而导致出现重大错误。如此，通过将历史区块对应的历史状态数据设置为只读状态，可以避免步骤220中执行交易后更新历史交易的状态数据。
[0148]
在一示例性的实施例中，所述交易执行结果包括执行交易后生成的交易收据；
[0149]
所述基于所述区块链支持的第一软件版本执行所述交易，得到第一交易执行结果；
[0150]
基于所述区块链支持的第一软件版本执行所述交易，生成针对所述初始账户状态对应的更新账户状态，并基于所述初始账户状态和所述更新账户状态生成所述交易对应于所述第一软件版本的第一交易收据；
[0151]
所述基于所述区块链支持的第二软件版本执行所述交易，得到第二交易执行结果，包括：
[0152]
基于所述区块链支持的第二软件版本执行所述交易，生成针对所述初始账户状态对应的更新账户状态，并基于所述初始账户状态和所述更新账户状态生成所述交易对应于所述第二软件版本的第二交易收据。
[0153]
其中，所述目标节点设备搭载了用于记录交易执行结果的服务端口；
[0154]
在所述将所述第一交易执行结果与所述第二交易执行结果进行匹配之前，还包括：
[0155]
调用所述服务端口，在本地存储生成的所述第一交易收据和所述第二交易收据。
[0156]
该示例中，所述服务端口可以将交易执行结果以交易收据的形式进行记录。具体可以是将交易收据存储到mpt收据树中。
[0157]
值得一提的是，假设将基于所述区块链支持的第一软件版本执行所述交易称为第一次执行交易；而将基于所述区块链支持的第二软件版本执行所述交易称为第二次执行交易。
[0158]
那么，在第一次执行交易后，并得到第一交易收据后，还需要回滚(rollback)第一次执行的交易，从而将第一次执行交易后的更新账户状态恢复回初始账户状态。这样做的目的是不影响世界状态。
[0159]
由于第一次和第二次执行的是相同的交易，通常区块链在执行交易后会更新交易涉及到的账户状态。如果不回滚第一次执行的交易，那么在第二次执行时，相同交易的初始
账户状态就会不同，那么其结果也必然是不同的。因此，通过回滚，使得第一次执行交易不影响世界状态，进而不会影响第二次执行交易的执行结果。
[0160]
举例说明，假设某个交易是用户a向用户b转账10元，世界状态中用户a的账户余额为100元(初始账户状态)，用户b的账户余额为50元(初始账户状态)。
[0161]
那么，在第一次执行后，世界状态中用户a的账户余额就会变为90元(更新账户状态)，而用户b的账户余额就会变为60元(更新账户状态)。
[0162]
如果不回滚，那么在第二次执行时，是从用户a的账户余额90元中转账10元到用户b的账户余额60元。而不是最初所要执行的从用户a的账户余额100元中转账10元到用户b的账户余额50元。
[0163]
因此，需要回滚第一次执行的交易，使得世界状态维持在用户a的账户余额为100元，用户b的账户余额为50元。这样，在第二次执行时，就与第一次执行相同，都是从用户a的账户余额100元中转账10元到用户b的账户余额50元。
[0164]
值得一提的是，第一软件版本和第二软件版本可能存在版本逻辑的不同。从而在第一软件版本和第二软件版本执行相同交易时产生不同的交易收据。
[0165]
依然沿用前述示例，某个交易是用户a向用户b转账10元，世界状态中用户a的账户余额为100元，用户b的账户余额为50元。其中，新版本的区块链需要收取1元的手续费；旧版本的区块链需要收取2元的手续费。
[0166]
那么，在第一次执行交易后，得到的第一交易收据为，从用户a的账户余额100元中提取10元转到用户b的账户余额50元。并且，从用户a的账户余额100中额外提取2元的手续费。即用户a的账户余额剩余88元，用户b的账户余额为60元。
[0167]
在第二次执行交易后，得到的第二交易收据为，从用户a的账户余额100元中提取10元转到用户b的账户余额50元。并且，从用户a的账户余额100中额外提取1元的手续费。即用户a的账户余额剩余89元，用户b的账户余额为60元。
[0168]
可见，分别通过第一软件版本和第二软件版本执行相同交易，会由于版本逻辑差异导致交易收据的不同。
[0169]
为了解决这一问题，可以为第一软件版本和第二软件版本配置向前兼容的配置文件，所述配置文件包括第一软件版本和第二软件版本中存在差异的逻辑。如此可以弥补软件版本之间的差异。
[0170]
具体地，在第一次执行交易时，目标节点设备可以基于预先配置的配置文件，将第一软件版本和第二软件版本中存在差异的逻辑，替换为相同的逻辑。如此，通过配置文件，弥补新老版本之间的兼容差异，使得分别执行相同交易后不会因为版本逻辑原因导致不同。
[0171]
步骤230：将所述第一交易执行结果与所述第二交易执行结果进行匹配，并基于所述匹配的结果以确定所述第一软件版本与所述第二软件版本是否兼容。
[0172]
目标节点设备在得到第一交易执行结果和第二交易执行结果后，通过将所述第一交易执行结果与所述第二交易执行结果进行匹配，从而基于所述匹配的结果可以确定所述第一软件版本与所述第二软件版本是否兼容。
[0173]
在一示例性的实施例中，所述步骤230，可以包括：
[0174]
读取所述服务端口记录的所述第一交易收据和所述第二交易收据；
[0175]
将读取到的所述第一交易收据和所述第二交易收据进行匹配；
[0176]
如果所述第一交易收据与所述第二交易收据匹配，确定所述第一软件版本与所述第二软件版本兼容；反之，确定所述第一软件版本与所述第二软件版本不兼容。
[0177]
该示例中，所述第一交易收据与所述第二交易收据匹配可以是指第一交易收据和第二交易收据相同或一致。
[0178]
在实际应用总，在将读取到的所述第一交易收据和所述第二交易收据进行匹配时，可以获取所述第一交易收据所在交易收据树的第一根哈希，和所述第二交易收据所在交易收据树的第二根哈希；如果所述第一根哈希和第二根哈希一致，则确认所述第一交易收据和第二交易收据匹配。
[0179]
如前所述，所述交易收据是位于交易收据树上的，而交易收据树是一颗merkle树。对于merkle树来说，其根哈希是由树上所有数据哈希共同计算得到的。树上任意一个数据哈希的不同都会影响最终的根哈希。
[0180]
因此，在分别由第一软件版本和第二软件版本执行相同交易后，应当具有相同的交易收据树，也就应当具有相同的根哈希。如果两者的根哈希不一致，那么就可以确定两者存在兼容性问题。
[0181]
通过这种方式无需从交易收据树中查找到执行交易的交易收据，直接通过比较交易收据树的根哈希更为快速。
[0182]
在实际应用中，区块链中交易的类型可以包括创建帐号、创建合约、转账、发行资产、赎回资产等不同的类型。每种交易类型的执行都需要版本中相关逻辑的支持。
[0183]
通过图1所示实施例执行不同的交易类型，可以确定是什么类型的交易在执行什么版本区块链时存在兼容性问题。
[0184]
例如，在执行创建帐号交易时，交易收据是相同的，而在执行转账时，交易收据是不同的；那么就可以确定新版本中关于转账的版本逻辑存在兼容性问题。
[0185]
另外，当存在多个历史区块时，不同区块中交易类型也可以是不同的，如此可以验证不同交易类型下区块链软件版本之间是否存在兼容性问题。
[0186]
在一示例性的实施例中，当存在多个历史区块时，目标节点设备可以在多线程下并行以第一软件版本执行交易，以及以第二软件版本执行交易。
[0187]
该示例中，为了快速得到验证结果，可以在多线程下并行执行不同区块的交易；由于执行的区块之间不互相影响，且执行结果也不影响世界状态。相当于各区块处于隔离状态，因此这种多线程并行执行具有可行性，提高了验证速度。
[0188]
在一示例性的实施例中，所述区块链支持进行软件版本的灰度升级；所述第二软件版本包括将所述区块链中的部分节点设备支持的软件版本灰度升级为所述最新软件版本之前，所述部分节点设备支持的历史软件版本。
[0189]
相应地，在所述步骤210之前，还可以包括：
[0190]
响应于所述区块链中的部分节点设备支持的软件版本灰度升级为所述最新软件版本，获取待验证的历史区块，并从所述历史区块中读取待验证的交易。
[0191]
该示例中，所述灰度升级可以是指一种平滑过渡的升级方式。在灰度升级过程中，先采用a/b testing，即让一部分用户继续使用历史软件版本，一部分用户开始用最新软件版本；如果用户对最新软件版本没有什么反对意见，那么逐渐扩大最新软件版本的使用范
围，慢慢将所有用户都迁移到最新软件版本上。
[0192]
采用灰度升级的方式可以保证整体区块链的稳定运行，在初始灰度升级时就可以发现问题并及时处理，由于初始灰度升级的用户群体较少即使出现问题影响范围也有限。
[0193]
在一示例性的实施例中，如果确定所述最新软件版本与所述历史软件版本兼容，向所述区块链对应的服务平台发送升级指示，以触发所述服务平台将所述部分节点设备支持的软件版本由所述历史软件版本升级为所述最新软件版本。
[0194]
其中，所述服务平台包括用于提供区块链即服务(baas，blockchain as a service)的baas平台(也称之为baas云)。baas平台可以通过为区块链上发生的活动(诸如订阅和通知、用户验证、数据库管理和远程更新)，提供预先编写的软件的方式，面向与baas平台耦接的客户端侧计算设备，提供简单易用，一键部署，快速验证，灵活可定制的区块链服务，进而可以加速区块链业务应用开发、测试、上线，助力各行业区块链商业应用场景的落地。
[0195]
与上述方法实施例相对应，本说明书还提供了一种区块链版本兼容性验证装置的实施例。
[0196]
本说明书的区块链版本兼容性验证装置的实施例可以应用在电子设备上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在电子设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。
[0197]
从硬件层面而言，如图2所示，为本说明书的区块链版本兼容性验证装置所在电子设备的一种硬件结构图，除了图2所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的电子设备通常根据该电子设备的实际功能，还可以包括其他硬件，对此不再赘述。
[0198]
图3是本说明书一示例性实施例示出的一种区块链版本兼容性验证装置的框图。
[0199]
请参考图3，所述区块链版本兼容性验证装置可以应用在前述图2所示的电子设备中，所述装置应用于所述区块链中的目标节点设备；其中，所述区块链支持进行软件版本升级；所述装置包括：
[0200]
获取单元310，获取待验证的历史区块，并从所述历史区块中读取待验证的交易；
[0201]
执行单元320，基于所述区块链支持的第一软件版本执行所述交易，得到第一交易执行结果；以及，基于所述区块链支持的第二软件版本执行所述交易，得到第二交易执行结果；
[0202]
验证单元330，将所述第一交易执行结果与所述第二交易执行结果进行匹配，并基于所述匹配的结果以确定所述第一软件版本与所述第二软件版本是否兼容。
[0203]
可选的，在所述执行单元320之前，还包括：
[0204]
数据获取子单元，从所述区块链对应的历史状态数据库中，获取与所述历史区块对应的历史状态数据；其中，与所述历史区块对应的历史状态数据被设置为只读状态；从与所述历史区块对应的历史状态数据中读取与所述交易相关的区块链账户对应的初始账户状态。
[0205]
可选的，所述交易执行结果包括执行交易后生成的交易收据；
[0206]
所述执行单元320，进一步包括：
[0207]
第一执行子单元，基于所述区块链支持的第一软件版本执行所述交易，生成针对所述初始账户状态对应的更新账户状态，并基于所述初始账户状态和所述更新账户状态生成所述交易对应于所述第一软件版本的第一交易收据；
[0208]
第二执行子单元，基于所述区块链支持的第二软件版本执行所述交易，生成针对所述初始账户状态对应的更新账户状态，并基于所述初始账户状态和所述更新账户状态生成所述交易对应于所述第二软件版本的第二交易收据。
[0209]
可选的，所述目标节点设备搭载了用于记录交易执行结果的服务端口；
[0210]
在所述验证单元330之前，还包括：
[0211]
调用单元，调用所述服务端口，在本地存储生成的所述第一交易收据和所述第二交易收据。
[0212]
可选的，所述验证单元330，进一步包括：
[0213]
读取子单元，读取所述服务端口记录的所述第一交易收据和所述第二交易收据；
[0214]
匹配子单元，将读取到的所述第一交易收据和所述第二交易收据进行匹配；
[0215]
确定子单元，如果所述第一交易收据与所述第二交易收据匹配，确定所述第一软件版本与所述第二软件版本兼容；反之，确定所述第一软件版本与所述第二软件版本不兼容。
[0216]
可选的，所述获取单元310，进一步包括：获取用户指定的待验证的历史区块对应的区块号区间，从所述区块号区间中读取待验证的历史区块的区块号，并在本地维护的所述区块链的区块数据中读取与所述区块号对应的历史区块。
[0217]
可选的，所述本地维护的所述区块链的区块数据为预先拷贝至所述目标节点设备的区块数据。
[0218]
可选的，所述区块链支持进行软件版本的灰度升级；所述第一软件版本包括最新软件版本；所述第二软件版本包括将所述区块链中的部分节点设备支持的软件版本灰度升级为所述最新软件版本之前，所述部分节点设备支持的历史软件版本。
[0219]
可选的，在所述获取单元310之前，还包括：
[0220]
响应单元，响应于所述区块链中的部分节点设备支持的软件版本灰度升级为所述最新软件版本，获取待验证的历史区块，并从所述历史区块中读取待验证的交易。
[0221]
可选的，所述装置还包括：
[0222]
处理单元，如果确定所述最新软件版本与所述历史软件版本兼容，向所述区块链对应的服务平台发送升级指示，以触发所述服务平台将所述部分节点设备支持的软件版本由所述历史软件版本升级为所述最新软件版本。
[0223]
可选的，所述服务平台包括bass平台。
[0224]
可选的，所述目标节点设备包括所述区块链中预设的不参与共识的非共识节点。
[0225]
上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
[0226]
在一个典型的配置中，计算机包括一个或多个处理器(cpu)、输入/输出接口、网络
接口和内存。
[0227]
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flash ram)。内存是计算机可读介质的示例。
[0228]
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带、磁盘存储、量子存储器、基于石墨烯的存储介质或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
[0229]
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
[0230]
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实现方式中，多任务处理和并行处理也是可以的或者可能是有利的。
[0231]
在本说明书一个或多个实施例使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
[0232]
应当理解，尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在
……
时”或“当
……
时”或“响应于确定”。
[0233]
以上所述仅为本说明书一个或多个实施例的较佳实施例而已，并不用以限制本说明书一个或多个实施例，凡在本说明书一个或多个实施例的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书一个或多个实施例保护的范围之内。