发送控制方法、发送控制程序以及信息处理装置与流程

1.本发明涉及发送控制方法、发送控制程序以及信息处理装置。


背景技术：

2.区块链是将存储有1个以上的事务(a先生/女士向b先生/女士汇款100日元等这样的交易内容)的区块以串珠的形式连接成链状而成的，通过构成p2p网络(区块链网络)的多个节点而进行分散管理。另外，由于在各区块中包含前1个区块的哈希值，因此难以篡改各区块。
3.在将存储有新事务的区块与链连接(以下，将这样的处理称为“写(write)”。)时，构成区块链网络的全部节点进行事务的验证。该验证主要是进行区块生成节点的署名的验证以及事务的input/output(输入/输出)与节点的当前状态匹配的验证的处理，占据节点所执行的处理的大部分。
4.另一方面，在参照与区块链连接的任意区块内的事务(以下称为“读(read)”。)时，不进行新区块的生成或该事务的验证。
5.现有技术文献
6.专利文献
7.专利文献1：日本特开2018-128723号公报


技术实现要素：

8.发明要解决的问题
9.但是，在每次进行“写”时参加区块链网络的全部节点进行事务的验证的情况下，例如具有如下问题。
10.(1)在“写”的频度比“读”多(例如，目的是将数据作为踪迹而残留在区块链中)的情况下，全部节点的处理效率差(处理负载高)。
11.(2)也有时对没有被“读”的数据进行验证，效率差。
12.于是，在一个方案中，目的在于，抑制区块链网络所包含的节点的处理负载。
13.用于解决问题的手段
14.在一个方案中，在存储在区块链所包含的区块中的事务的发送控制方法中，计算机执行以下处理：在接收到所述事务的参照请求时，向包含在区块链网络中的节点发送所述事务的验证请求，在接收到基于所述节点的验证结果时，生成存储有所述验证结果的验证区块，将生成的所述验证区块与所述区块链连接，并且，基于所述验证结果，控制是否向所述参照请求的请求源发送所述事务。
15.发明的效果
16.根据一个方案，能够抑制区块链网络所包含的节点的处理负载。
附图说明
17.图1是示出本发明的实施方式中的事务管理系统1的结构例的图。
18.图2是示出构成本发明的实施方式中的事务管理系统1的各节点的硬件结构例的图。
19.图3是示出本发明的实施方式中的事务管理系统1的功能结构例的图。
20.图4是用于说明在“写”时由事务管理系统1执行的处理步骤的一例的时序图。
21.图5是示出状态db(data base：数据库)27的结构例的图。
22.图6是用于说明在“读”时由事务管理系统1执行的处理步骤的一例的时序图。
23.图7是示出连接有验证区块的区块链的一例的图。
具体实施方式
24.以下，基于附图对本发明的实施方式进行说明。图1是示出本发明的实施方式中的事务管理系统1的结构例的图。在图1中，多个用户终端50经由因特网等网络而与事务管理系统1连接。
25.用户终端50是汇款等各种交易(以下称为“事务”。)的当事人所利用的终端。例如，pc(personal computer：个人计算机)、智能手机或平板终端等也可以用作用户终端50。
26.事务管理系统1是对在用户终端50之间进行的事务进行管理的p2p网络(区块链网络)，包含应用了分散型账本技术的多个计算机或信息处理装置(节点)的集合。各节点通过区块链网络而连接，具有对共同的账本信息进行分散管理的存储部(以下，称为“账本”。)。在账本中记录有表示事务的历史的区块链。在本实施方式中，将向记录在账本中的区块链连接(追加)新区块的处理称为“写”，将参照与区块链连接的任意的区块内的事务的处理称为“读”。
27.在本实施方式中，事务管理系统1并非在“写”时而是在“读”时实施事务的验证，由此，能够削减事务的验证所耗费的资源，并且能够高效且可靠地进行事务的验证。另外，为了显著地得到这样的效果，在事务管理系统1中，优选向区块链进行的“写”的频度相对多于“读”的频度。
28.此外，优选节点的参加为许可制且区块链不分支的联盟型区块链(例如，hyperledger fabric(超级账本架构)等)作为事务管理系统1。
29.此外，在事务管理系统1中具备与以往的区块链相关的以下机制。
30.·
在单一或多个节点中配备、共享、执行智能合约的机制。
31.·
经由智能合约进行事务的生成和参照的机制。
32.·
从中途起动、重新起动的节点共享到最新区块为止的区块链的机制。
33.·
生成事务的节点向全部节点分发包含该事务的区块的机制(通过某种方法来保证区块的顺序。)。
34.此外，事务管理系统1具有以下4个功能。
35.(1)[事务生成/写入功能]
[0036]
当使用智能合约等生成了事务的节点生成区块并向参加到区块链网络中的全部节点分发区块时，接收到该区块的各节点不进行事务的验证而对该区块进行“写”。此外，用于参照事务的信息(事务id等确定事务的信息)被存储在节点内的数据库中。
[0037]
(2)[事务参照功能]
[0038]
当使用智能合约等而参照了事务的节点向包含自身的参加到区块链网络中的全部节点分发该事务并请求该事务的验证时，收到请求的各节点对事务进行验证并返回验证结果和针对验证的署名。此外，将参照了事务的节点所收集到的全部节点的验证结果和署名存储于区块(以下称为“验证区块”。)，并向全部节点分发验证区块。另外，验证区块存储前1个区块的哈希值、验证对象的事务的哈希值等。
[0039]
(3)[依赖事务的参照/验证功能]
[0040]
关于(1)的事务生成/写入功能，在刚刚使用智能合约等生成了事务之后，针对生成的事务所依赖的过去的事务，执行(2)的事务参照功能。
[0041]
(4)[事务验证结果的缓存功能]
[0042]
关于(2)的事务参照功能，将被进行了一次参照(“读”)的事务的验证结果缓存于节点内的数据库。在参照事务时，从节点内的数据库中检索被参照的事务的验证结果，在不存在验证结果的情况下进行事务的验证。
[0043]
即，在本实施方式中，在通过智能合约的执行而生成的事务的“写”时，不进行事务的验证而将存储有该事务的区块分发到全部节点。但是，在“写”对象的事务依赖于过去的事务的情况下(例如，在“写”对象的事务是依赖于过去的余额的金钱交易的事务等的情况下)，执行过去的事务的“读”。此外，在事务的“读”时，通过智能合约的执行而参照了事务的节点向全部节点请求该事务的验证，收集验证结果和署名，将该验证结果和署名存储于验证区块并向全部节点分发该验证区块。此时，验证结果被缓存于节点内的数据库。因此，在事务的“读”时，在节点内的数据库缓存有验证结果的情况下，不执行该事务的验证的请求之后的处理，抑制了验证区块的生成。
[0044]
图2是示出构成本发明的实施方式中的事务管理系统1的各节点的硬件结构例的图。如图2所示，各节点具有分别通过总线b相互连接的驱动器装置101、辅助存储装置102、存储器装置103、cpu 104以及接口装置105等。
[0045]
由记录介质106提供实现节点中的处理的程序。当将记录有程序的记录介质106设置于驱动器装置101时，将程序从记录介质106经由驱动器装置101安装于辅助存储装置102。但是，程序的安装并非必须通过记录介质106来进行，也可以经由网络从其他计算机下载。辅助存储装置102存储所安装的程序，并且存储需要的文件、数据等。
[0046]
存储器装置103在存在程序的起动指示的情况下，从辅助存储装置102读出并存储程序。cpu 104按照存储于存储器装置103的程序来执行与节点有关的功能。接口装置105用作用于与网络连接的接口。
[0047]
另外，作为记录介质106的一例，可举出cd-rom、dvd盘或者usb存储器等可移动型的记录介质。此外，作为辅助存储装置102的一例，可举出hdd(hard disk drive：硬盘驱动器)或闪存等。记录介质106和辅助存储装置102中的任意一个都相当于计算机可读取的记录介质。
[0048]
图3是示出本发明的实施方式中的事务管理系统1的功能结构例的图。在本实施方式中，为了方便，示出事务管理系统1基于联盟型区块链架构“hyper ledger fabric”的例子。但是，也可以采用其他的区块链架构。
[0049]
在图3中，事务管理系统1包含作为对等节点(peer)20发挥功能的多个节点、作为
排序节点(orderer)30发挥功能的1个节点、以及作为链码(chaincode)40发挥功能的1个节点。这里，节点是1个或多个计算机。但是，事务管理系统1也可以包含多个排序节点30和多个链码40。
[0050]
排序节点30是生成区块并将该区块分发到各对等节点20的节点。在图3中，排序节点30具有tx区块生成部31和验证区块生成部32等。这些各部是通过安装于排序节点30的1个以上的程序使排序节点30的cpu 104执行的处理而实现的。
[0051]
tx区块生成部31生成包含与事务相关的数据(以下称为“事务数据”。)的区块(以下称为“tx区块”。)。验证区块生成部32生成验证区块。
[0052]
对等节点20分散地管理记录有区块链的共同的账本信息。对等节点20从用户终端50受理事务的“写”请求或“读”请求，控制与这些请求相应的处理。在图3中，对等节点20具有tx收发部21、依赖tx检索部22、tx区块收发部23、tx验证部24、验证结果收发部25以及验证区块收发部26等。这些各部是通过安装于对等节点20的1个以上的程序使对等节点20的cpu 104执行的处理而实现的。对等节点20还利用状态db 27和账本28等存储部。这些各存储部例如能够使用辅助存储装置102或者可经由网络与对等节点20连接的存储装置等来实现。
[0053]
tx收发部21从用户终端50接收“写”请求或者“读”请求，控制与这些请求相应的处理。
[0054]
依赖tx检索部22从状态db 27中检索“写”请求的对象的事务所依赖的(该事务的依赖对象的)事务。在状态db 27中存储有与各事务相关的数据。在本实施方式中，状态db 27也用作用于缓存各事务的验证结果的存储部。另外，worldstate等也可以用作状态db 27。
[0055]
tx区块收发部23从tx区块生成部31接收由tx区块生成部31生成的tx区块并将该tx区块记录于账本28，并且，向作为“写”请求源的用户终端50发送该tx区块的确定的通知。账本28是存储区块链的存储部。
[0056]
tx验证部24针对作为“读”的对象的事务以及作为“写”的对象的事务所依赖的事务中的未验证的事务进行验证。
[0057]
验证结果收发部25从tx验证部24接收事务的验证结果，向验证区块生成部32发送存储该验证结果的验证区块的生成请求。
[0058]
验证区块收发部26从验证区块生成部32接收由验证区块生成部32生成的验证区块并将该验证区块记录于账本28，并且，向作为“读”请求源的用户终端50发送该验证区块的确定的通知。
[0059]
链码40是安装有智能合约的节点。在图3中，链码40具有tx生成部41和tx参照部42等。这些各部是通过安装于链码40的1个以上的程序(智能合约)使链码40的cpu 104执行的处理而实现的。
[0060]
tx生成部41生成“写”对象的事务的事务数据。tx参照部42从状态db 27中检索“读”对象的事务的事务数据。
[0061]
另外，用户终端50具有客户端部51。客户端部51是通过安装于用户终端50的1个以上的程序(例如，与事务管理系统1对应的应用程序)使用户终端50的cpu执行的处理而实现的。
[0062]
客户端部51对事务管理系统1发送各种请求(request)，并接收针对该请求的响应(response)。
[0063]
另外，在图3中，示出了将节点分类为排序节点30、链码40以及对等节点20的例子，但也可以根据所采用的区块链架构，使全部的对等节点20或一部分的对等节点20具有排序节点30或者链码40的功能。即，可以采用不区分排序节点30、链码40以及对等节点20的结构。
[0064]
以下，对事务管理系统1所执行的处理步骤进行说明。图4是用于说明在“写”时由事务管理系统1执行的处理步骤的一例的时序图。
[0065]
在步骤s101中，用户终端50的客户端部51向1个对等节点20(以下称为“对象对等节点20”。)发送某个事务(以下称为“对象事务”。)的“写”请求。该“写”请求中包含表示对象事务的内容的事务信息(例如，汇款方、汇款目的地以及汇款额等)。
[0066]
对象对等节点20的tx收发部21在接收到该“写”请求时，向链码40的tx生成部41发送对象事务的事务数据(以下称为“对象tx”。)的生成请求(s102)。该生成请求中包含对象事务的事务信息。
[0067]
tx生成部41根据该生成请求，执行智能合约(chaincode)而生成对象tx(s103)，并向对象对等节点20的tx收发部21发送包含对象tx的响应(s104)。另外，在对象tx中，包含作为对象事务的识别码的事务id(以下称为“txid”。)、事务信息、以及与对象事务的对象相关的识别码(以下称为“键”。)等。键的值例如是“a先生/女士的储蓄账户的账号”等。
[0068]
tx收发部21在接收到来自tx生成部41的响应时，向对象对等节点20的依赖tx检索部22发送该响应所包含的对象tx(s105)。依赖tx检索部22在接收到对象tx时，参照状态db 27，判定对象事务所依赖的其他事务的有无(s106、s107)。
[0069]
图5是示出状态db 27的结构例的图。如图5所示，在状态db 27中，按照每个事务而存储有区块编号、txid、键(版本)以及验证结果等。
[0070]
区块编号是存储事务数据的tx区块的编号。txid是事务的识别码。键(版本)是事务的键和该键的版本。在图5中，键值由字母表中的一个字符抽象化地表现。键的版本在每次执行与同一键相关的事务时其值增加(在图5的例子中加1。)。验证结果是针对事务进行了验证的每个对等节点20的验证结果。
[0071]
在步骤s106和s107中，依赖tx检索部22检索包含与对象tx的键相同的键的记录，判定该记录是否存储在状态db 27中。在相符的记录存在的情况下，依赖tx检索部22判定为存在对象tx所依赖的事务的事务数据(以下称为“依赖tx”。)，在相符的记录不存在的情况下，依赖tx检索部22判定为不存在依赖tx。另外，根据图5的例子，现有的记录包含的键值为“a”或“b”。因此，如果对象tx的键值为“a”或“b”，则判定为存在依赖tx，在该键值既不是“a”也不是“b”的情况下，判定为不存在依赖tx。
[0072]
在判定为存在依赖tx的情况下，依赖tx检索部22向对象对等节点的tx收发部21发送依赖tx的“读”请求(s111)。该“读”请求中例如包含依赖tx的txid。接下来，执行依赖tx的“读”处理(s112)。除了“读”的对象是依赖tx之外，该“读”处理与后述的图6的处理f1(步骤s211～s231)相同。另外，在步骤s112中依赖tx的验证成功的情况下(在基于全部的对等节点20的验证结果为ok的情况下)，向步骤s101的“写”请求的发送源的客户端部51发送对象tx，在验证失败的情况下(在基于任意1个以上的对等节点20的验证结果为ng的情况下)，向
该客户端部51发送表示验证错误的信息。
[0073]
另一方面，在判定为不存在依赖tx的情况下，依赖tx检索部22向对象对等节点20的tx收发部21发送在步骤s103中生成的对象tx(s121)。tx收发部21向步骤s101的“写”请求的发送源的客户端部51发送对象tx(s122)。
[0074]
在步骤s112中接收到对象tx的情况下，或者在步骤s122之后，客户端部51向排序节点30的tx区块生成部31发送存储对象tx的区块的生成请求(s131)。该生成请求中包含对象tx。tx区块生成部31在接收到该生成请求时，生成用于存储该生成请求所包含的对象tx的tx区块(以下称为“对象tx区块”。)(s132)，并向各对等节点的tx区块收发部23分发(发送)对象tx区块(s133、s134)。对象tx区块中包含对象tx的区块编号等。
[0075]
对象区块的tx区块收发部23将对象tx区块记录于对象对等节点20的账本28(s135)。即，在记录于该账本28的区块链中连接对象tx区块。此时，不执行对象tx的验证。接下来，tx区块收发部23将包含对象tx的事务数据的记录登记于状态db 27(s136)。具体而言，将包含对象tx区块的区块编号、对象tx的txid、对象tx的键以及该键的版本的记录登记于状态db 27。这里，作为键的版本，在存在依赖tx的情况下，登记对最后的依赖tx的版本登记加上1后的值，在不存在依赖tx的情况下，登记0。另外，在该时间点下，不登记与对象tx相关的验证结果。这是因为，在“写”时不进行对象tx的验证。
[0076]
接下来，tx区块收发部23向“写”请求的发送源的客户端部51发送表示对象tx区块(已与区块链连接)已确定的通知(s137)。
[0077]
另外，对象对等节点20以外的其他的各对等节点20的tx区块收发部23根据对象tx区块的接收，执行与步骤s135～s137相同的处理(s140)。因此，也从这些其他的各对等节点20向客户端部51发送表示对象tx区块已确定的通知。
[0078]
图6是用于说明在“读”时由事务管理系统1执行的处理步骤的一例的时序图。
[0079]
在步骤s201中，用户终端50的客户端部51向1个对等节点20(以下称为“对象对等节点20”。)发送某个事务(以下称为“对象事务”。)的“读”请求(参照请求)。该“读”请求中包含对象事务的特定信息(例如，txid等)。
[0080]
对象对等节点20的tx收发部21在接收到该“读”请求时，指定该特定信息，向对象对等节点20的tx参照部42发送对象事务的事务数据的检索请求(s202)。tx参照部42在接收到该检索请求时，执行智能合约(chaincode)，从状态db 27中检索与该检索请求所指定的特定信息有关的记录(s203)，取得记录在该记录中的区块编号、txid以及键(版本)(以下，将包含它们的数据称为“对象tx”。)和验证结果(s204)。tx参照部42向对象对等节点20的tx收发部21发送包含所取得的对象tx和验证结果的检索结果(s205)。
[0081]
接下来，tx收发部21在接收到该检索结果时，判定该检索结果所包含的验证结果是否为空(即，验证结果的有无)。或者，在验证结果为空的情况下，检索结果中也可以不包含验证结果。在这种情况下，按照字符判定验证结果的有无即可。另外，针对对象tx(对象事务)的验证结果的有无的判定和与对象事务建立了对应的验证区块的有无的判定是等价的。如后述那样，这是因为，当执行对象事务的验证时，与对象事务对应起来地将验证区块记录于账本28。换言之，在步骤s203和s204中，也可以判定在记录于账本28的区块链中是否包含该验证区块。但是，通过利用状态db 27，能够使这样的判定高速化。
[0082]
在不存在验证结果的情况下(即，在与对象事务对应起来的验证区块不包含在账
本28中的情况下)，执行处理f1(步骤s211～s231)。
[0083]
在步骤s211中，tx收发部21向对象对等节点20的验证结果收发部25发送对象tx的验证请求。该验证请求中包含对象tx。验证结果收发部25根据该验证请求，向包含对象对等节点20的全部的对等节点20的tx验证部24发送该验证请求(s212、s213)。
[0084]
接收到该验证请求的各对等节点20的tx验证部24按照预先决定的算法对对象tx进行验证，并将作为验证结果(表示验证的成功与否(对象tx的正确与否)的信息)的“ok”或“ng”和针对验证结果的署名向对象对等节点20的验证结果收发部25发送(s214、s215)。
[0085]
对象对等节点20的验证结果收发部25在接收到(收集到)来自全部对等节点20的tx验证部24的验证结果和署名时，向排序节点30的验证区块生成部32发送验证区块的生成请求(s216)。该生成请求中包含全部对等节点20的验证结果和署名。
[0086]
验证区块生成部32根据该生成请求，生成包括该生成请求所包含的全部的验证结果和署名在内的验证区块(s217)。此时，验证区块生成部32在验证区块的区块头中存储prehash(＝在区块链中前1个区块的哈希值)和pretx(＝对象tx的txid)。即，验证区块生成部32将对象tx的txid包含在验证区块的区块头中，从而在验证区块向区块链连接时(伴随着连接)，将验证区块与对象事务对应起来。接下来，验证区块生成部32向包括对象对等节点20在内的全部的对等节点20的验证区块收发部26发送(分发)验证区块(s218、s219)。
[0087]
对象对等节点20的验证区块收发部26在接收到验证区块时，将验证区块记录于对象对等节点20的账本28(s220)。即，验证区块收发部26将验证区块连接到记录在账本28中的区块链。
[0088]
图7是示出连接有验证区块的区块链的一例的图。在图7中，示出了记录在账本28中的包含区块b0～区块b5的区块链。其中，区块b0、b1、b2以及b4是tx区块，区块b3和b5是验证区块。即，区块b3是与存储于区块b1的事务数据tx1对应的验证区块。区块b5是与存储于区块b1的事务数据tx2对应的验证区块。例如，在对象tx为tx2的情况下，在步骤s220中，区块b5与区块链连接。
[0089]
接下来，验证区块收发部26在对象对等节点20的状态db 27中的与对象tx对应的记录(包含对象tx的txid的记录)的验证结果中登记验证区块所包含的验证结果(即，基于全部对等节点20的对象tx的验证结果)(s221)。其结果是，对象事务的验证结果被缓存于状态db 27。接下来，验证区块收发部26向对象对等节点20的tx收发部21发送验证区块和验证区块的确定通知(s222)。
[0090]
另外，对象对等节点20以外的其他的各对等节点20的验证区块收发部26根据验证区块的接收，执行与步骤s220和s221相同的处理(s230)。接下来，这些各对等节点20的验证区块收发部26向对象对等节点20的tx收发部21发送验证区块的确定通知(s231)。另外，在步骤s231中可以不发送验证区块。
[0091]
对象对等节点20的tx收发部21在从全部对等节点20的验证区块收发部26接收到验证区块的确定通知时，将从对象对等节点20的验证区块收发部26接收到的验证区块所包含的全部对等节点20的验证结果作为处理对象而执行步骤s241。
[0092]
另一方面，在步骤s205中的来自tx参照部42的检索结果中包含验证结果的情况下(即，在对象事务的验证区块包含于账本28的情况下)，对象对等节点20的tx收发部21不执行步骤s211。其结果是，不执行处理f1(步骤s211～s231)，将该验证结果作为处理对象而执
行步骤s241。即，在对象事务的验证区块包含于账本28的情况下，tx收发部21抑制生成对象事务的验证区块。
[0093]
在步骤s241中，对象对等节点20的tx收发部21基于处理对象的检索结果，控制是否向“读”请求的发送源(请求源)发送对象tx。具体而言，在该检索结果表示全部的对等节点20的验证结果为ok的情况下，tx收发部21向“读”请求的发送源的客户端部51发送对象tx(s241)。另一方面，在该检索结果表示1个以上的对等节点20的验证结果为ng(对象tx不合法)的情况下，tx收发部21向客户端部51发送验证错误的消息(s241)。
[0094]
如上所述，根据本实施方式，不是在登记事务时(存储有该事务的区块向区块链连接时)而是在参照事务时对该事务进行验证。因此，能够将验证对象的事务减少到参照对象的事务，由此，能够抑制区块链网络所包含的节点的处理负载。
[0095]
例如，在区块链架构“hyper ledger fabric”的情况下，验证所耗费的时间为“写”所耗费的时间的约20％，因此，能够期待“写”所耗费的处理时间削减约20％。
[0096]
此外，例如，在30分钟内进行一次p2p电力交易的情况下，“写”(记录电表的值)大约为1个事务/min，“读”(参照电力交易时的电力量)大约为1个事务/30min。由于通过简单计算对全部数据量的1/30进行“读”，因此，整体上能够期待削减验证所耗费的资源(时间、数据量)的约97％。
[0097]
此外，根据本实施方式，在对事务进行“写”的前阶段(节点刚刚执行了智能合约之后)，执行与该事务相关的其他事务(依赖事务)的“读”，因此，即便在要“写”的事务依赖于过去的事务的情况下，也能够保证过去的事务是合法的。
[0098]
此外，根据本实施方式，在进行了一次“读”的事务的验证结果被缓存于节点内的数据库(状态db 27)且针对过去已验证的事务请求了“读”时，基于该缓存来抑制验证。因此，能够避免针对同一事务重复地进行验证。
[0099]
以上，对本发明的实施方式进行了详述，但本发明不限定于上述特定的实施方式，在权利要求书所记载的本发明的主旨的范围内能够进行各种变形/变更。
[0100]
附图标记说明
[0101]1ꢀꢀꢀꢀꢀ
事务管理系统
[0102]
20
ꢀꢀꢀꢀ
对等节点
[0103]
21
ꢀꢀꢀꢀ
tx收发部
[0104]
22
ꢀꢀꢀꢀ
依赖tx检索部
[0105]
23
ꢀꢀꢀꢀ
tx区块收发部
[0106]
24
ꢀꢀꢀꢀ
tx验证部
[0107]
25
ꢀꢀꢀꢀ
验证结果收发部
[0108]
26
ꢀꢀꢀꢀ
验证区块收发部
[0109]
27
ꢀꢀꢀꢀ
状态db
[0110]
28
ꢀꢀꢀꢀ
账本
[0111]
30
ꢀꢀꢀꢀ
排序节点
[0112]
31
ꢀꢀꢀꢀ
tx区块生成部
[0113]
32
ꢀꢀꢀꢀ
验证区块生成部
[0114]
40
ꢀꢀꢀꢀ
链码
[0115]
41
ꢀꢀꢀꢀ
tx生成部
[0116]
42
ꢀꢀꢀꢀ
tx参照部
[0117]
50
ꢀꢀꢀꢀ
用户终端
[0118]
51
ꢀꢀꢀꢀ
客户端部
[0119]
101
ꢀꢀꢀ
驱动器装置
[0120]
102
ꢀꢀꢀ
辅助存储装置
[0121]
103
ꢀꢀꢀ
存储器装置
[0122]
104
ꢀꢀꢀ
cpu
[0123]
105
ꢀꢀꢀ
接口装置
[0124]
106
ꢀꢀꢀ
记录介质
[0125]bꢀꢀꢀꢀꢀ
总线