GB2593109A

GB2593109A - Reliability verification system for digital-asset data packet

Info

Publication number: GB2593109A
Application number: GB2108535.2A
Authority: GB
Inventors: Bai Jie
Original assignee: Jiangsu Aowei Holding Co Ltd
Current assignee: Jiangsu Aowei Holding Co Ltd
Priority date: 2020-09-21
Filing date: 2021-06-15
Publication date: 2021-09-15
Also published as: WO2022057106A1; CN111833062A; CN111833062B; JP2022051652A; JP6911231B1; GB202108535D0

Abstract

A reliability verification system for digital asset data packets (such as blockchain transactions) comprises an execution node, a collection node and a verification node. The execution node may comprise several nodes on different parent chains or subchains, with each node performing a different operation on the data packet, such as generating, transacting, storing or verifying digital assets, or running a platform for justice, evaluation, due diligence or guarantees. The verification node sends a request to verify the reliability of the digital asset data packet to the execution node. In response, each execution node uses its private key to digitally sign the data packet. The verification node verifies these digital signatures and, if they pass verification, triggers the collection node to collect these signatures into a single collective signature. When the collection node first collects the digital signatures, it also verifies all the individual digital signatures. If all the signatures pass verification, the collection node verifies an initial collective signature result. The verification node now considers the data packet to be credible if the collective signature passes verification. This avoids the need to verify each of the multiple digital signatures from the execution node to determine the data packet’s credibility.

Description

RELIABILITY VERIFICATION SYSTEM FOR DIGITAL-ASSET DATA

PACKET

FIELD OF THE INVENTION

[0001] This application relates to the field of Internet data processing, and in particular, to a reliability verification system for a digital-asset data packet that is based on a blockchain network

BACKGROUND OF THE INVENTION

[0002] A digital asset financial system usually takes a blockchain as a bearer network, to resolve problems such as reliability of a digital asset. Each function, such as generation and transaction of the digital asset, of the system usually is implemented by different nodes or subchains of a public chain. For a schematic diagram of a simple blockchain network shown in FIG. 1, different nodes are configured to implement different functions or operations. A network P shown in FIG 1 may be taken as a simple public chain, where node 1 is configured to generate the digital asset, and node 2 is configured to transact the digital asset. Moreover, for a schematic diagram of a typical blockchain network shown in FIG 2, different functions or operations are implemented by different subchains or nodes of the subchains. As shown in FIG 2, the public chain P is connected with four subchains, where subchain 3 is a digital asset generation subchain, and is referred to as a generation subchain for short; subchain 4 is a digital asset transaction subchain, and is referred to as a transaction subchain for short; subchain 5 is a digital asset storage subchain, and is referred to as a storage subchain for short; and subchain 6 is a digital asset verification subchain, and is referred to as a verification subchain for short. In FIG 1 or FIG 2, the nodes for implementing different functions or operations are usually determined by a conventional technical mechanism of the blockchain network, such as a voting or competitive mechanism. In addition, a cross-chain operation between the subchains shown in FIG 2 through the public chain is not discussed herein.

[0003] The blockchain network shown in FIG 2 is a typical bearer network of the digital asset financial system. Functions and operations of the subchains are related to each other. For example, a data structure and mechanism used by the generation subchain 3 is related to a data structure and mechanism used by a function implemented by another subchain, such as the verification subchain 6, or otherwise the corresponding function or operation cannot be implemented. Relationships among various subchains in FIG. 2 are described with reference to FIG. 3.

[0004] The subchain 3 shown in FIG 2, serving as an example of a digital asset generation subchain, includes a digital asset generation node 31 that is configured to bear and generate a digital asset generation platform. Other nodes 32, 33, 34, and 35 are configured to bear a justice platform, an evaluation platform, a due diligence platform, a guarantee platform, and the like.

Each platform is linked to one or more subchains composed of terminal nodes that are formed by a plurality of nodes. Refer to FIG. 3, FIG. 3 is a diagram about a relationship between the subchains of the digital asset financial system borne by the blockchain network shown in FIG. 2. The digital-asset data packet A generated by the digital asset generation node 31 is transferred to the nodes 32, 33, 34, and 35, to generate certain attributes bl, b2, b3, and b4 of the digital-asset data packet A, such as data for expressing an evaluated value, a justice item, data about a due diligence, and a guarantee item. These attributes bl, b2, b3, and b4 form attribute B of the digital-asset data packet A after being processed by the node 31. The digital-asset data packet A and the attribute B together compose a tradable digital-asset data packet D. The digital-asset data packet D is sent to the transaction subchain 4 and the storage subchain 5 by the node 31 for the transaction subchain 4 to verify a transaction or to be stored by the storage subchain 5.

Alternatively, the digital-asset data packet D is sent to the storage subchain 5 by the node 31, and the transaction subchain 4 obtains the tradable digital-asset data packet D from the subchain 5. Obviously, the digital-asset data packet D needs to be credible, so as to be able to be stored by the subchain 5 or be transacted by the transaction subchain 4.

[0005] However, due to various reasons, such as a node fails or a node is attacked, the blockchain network cannot ensure that the digital-asset data packet is credible, that is, cannot ensure that the digital-asset data packet stored by the storage subchain 5 is completely credible. A method for ensuring reliability is that the digital-asset data packet can be verified. A common practice is that any platform or any blockchain node initiates a verification request for a digital-asset data packet by using a credible node, to further verify each verification sub-item of the digital-asset data packet. For example, in FIG. 2, the nodes 32, 33, 34, and 35 may all be provided with differentiated services by a plurality of terminals during a same period or different periods. In other words, some attributes bl, b2, b3, or b4 of the digital-asset data packet A may all be products operated in cooperation by a plurality of terminals. Therefore, the reliability of the digital-asset data packet is achieved by reliability of each terminal operation.

Verifying the reliability of the digital-asset data packet is to verify the reliability of each terminal operation. A common practice is performing a hash signature to operation results of all terminals, that is, the attribute B or the digital-asset data packet D that is finally formed. In this way, a node for verification may obtain a conclusion on the reliability of the attribute B or the digital-asset data packet D by performing a hash calculation to the attribute B or the digital-asset data packet D. Obviously, in this way, reliability during a forming process and original reliability of the attribute B or the digital-asset data packet D cannot be ensured.

[0006] A method for improving is verifying an operator of the attribute B or the digital-asset data packet D. The verification operation usually has a verification requirement at uncertain time after the attribute B or the digital-asset data packet D is generated. Therefore, source tracing and verifying operators one by one by using this method require complex retrieving and deleting operations, and thus a lot of blockchain service nodes are involved and a data volume is large. As a result, a lot of resources are wasted and efficiency is relatively low.

SUMMARY OF THE INVENTION

[0007] On the basis of the foregoing technical problem, this application provides a reliability verification system for a digital-asset data packet. A problem to be resolved by this application is to provide a reliability verification system for a digital-asset data packet that wastes few resources and has high efficiency.

[0008] A reliability verification system for a digital-asset data packet, including several execution terminal nodes, several collection nodes, and several verification nodes, where the execution terminal node includes a plurality of nodes on different parent chains or subchains that perform operations to the digital-asset data packet, the collection node is a node that is pre-imparted with a corresponding collection functional role, and the verification node is a node that is pre-imparted with a corresponding verification functional role, wherein the verification node is configured with: a verification request step: sending a reliability verification request for the digital-asset data packet to the execution terminal node; the execution terminal node is configured with: a verification receiving step: receiving the verification request sent by the verification node; a digital signing step: performing a digital signature to the data packet by using respective private keys of the execution terminal nodes, where there is at least one digital signature; the verification node is further configured with: a digital signature verification step: verifying the digital signature; a collection triggering step: if every digital signature passes the verification, triggering the collection node to collect the digital signature; the collection node is configured with: a signature collection step: collecting the digital signature, to generate a collective signature; and the verification node is further configured with: a collective signature verification step: verifying the collective signature, where if the verification is passed, it indicates that the data packet is credible.

[0009] It may be learned from the foregoing technical solutions that this application provides a reliability verification system for a digital-asset data packet, including several execution terminal nodes, several collection nodes, and several verification nodes, where the execution terminal node includes a plurality of nodes on different parent chains or subchains that perform operations to the digital-asset data packet, the collection node is a node that is pre-imparted with a corresponding collection functional role, and the verification node is a node that is pre-imparted with a corresponding verification functional role. First, the verification node sends a reliability verification request for the digital-asset data packet to the execution terminal node.

The execution terminal node receives the verification request, and performs a digital signature to the data packet by using respective private keys of the execution terminal nodes. The verification node verifies the digital signature, and triggers the collection node to collect the digital signature if every digital signature passes the verification. The collection node collects the digital signature, to generate a collective signature. The verification node verifies a collective signature result, and if the verification is passed, it indicates that the data packet is credible. The collective signature only needs to pass the verification for one time, thus greatly reducing costs in verifying the signature, and saving storage space of the execution terminal node that is occupied.

[0010] In some embodiments, the execution terminal node is further configured with a node reliability determining step: determining whether the verification node is a credible node, receiving the reliability verification request if the verification node is credible, and refusing the reliability verification request if the verification node is not credible.

[0011] In some embodiments, the collection node is further configured with: an initial verification step: verifying all the digital signatures when the collection node collects the digital signatures for the first time; and a collection result verification step: verifying a initial collective signature result if all the digital signatures pass the verification, wherein a verification mariner of the collective signature result is pre-determined by the verification node.

[0012] In some embodiments, the execution terminal node is further configured with: a trusted tree generation step: generating a trusted tree of a processing process of the data packet according to a node level based on a transaction operation process of the execution terminal node for the data packet; a trusted tree encryption step: encrypting each transaction operation in the trusted tree; a trusted tree verification step: verifying each transaction operation, to determine whether there is a malicious operation; a trusted tree storing step: if there is a malicious operation, recording an execution terminal node corresponding to the malicious operation, and provisionally storing the trusted tree according to preset time.

[0013] In some embodiments, the signature collection is performing signature collection to the digital signature based on the trusted tree.

[0014] In some embodiments, a collection node determining step comprises: a root node determining step: determining an execution terminal node that operates the data packet for the first time as a root node; and a subnode determining step: taking the root node as a level-1 node, taking a next-level node of the root node as a level-2 node, and taking a next-level node of the level-2 node as a level-3 node, until all nodes passed by the data packet are recorded.

[0015] In some embodiments, the digital signing step specifically comprises: a digest generation step: generating digital digest for original data of the data packet through a hash calculation; a digest encryption step: encrypting the digital digest by using the private key of a node where the data packet is located, to obtain the digital signature; a digital signature sending step: sending the digital signature and the original data of the data packet to the verification node together.

[0016] In some embodiments, a manner of verifying the digital signature is pre-negotiated and determined by the verification node and the execution terminal node.

[0017] In some embodiments, the several verification nodes at least comprise one credible node.

[0018] In some embodiments, the verification node is further configured with: a data packet storing step: if the data packet is credible, storing the data packet at the verification node, wherein the data packet storing step specifically comprises: a data packet splitting step: splitting the credible data packet to obtain a plurality of grouping data packets; a grouping data packet encryption step: encrypting each grouping data packet; an encrypted data packet storing step: storing each encrypted grouping data packet to the verification node.

BRIEF DESCRIPTION OF THE DRAWINGS

[0019] To more clearly describe the technical solutions of the embodiments of this application or in the prior art, the accompanying drawings required in the embodiments are briefly illustrated below. Apparently, the accompanying drawings in the description below are merely some embodiments of this application, and other accompanying drawings may also be obtained by one of ordinary skills in the art according to these accompanying drawings without a creative effort.

[0020] FIG 1 is a schematic diagram of a simple blockchain network; [0021] FIG. 2 is a schematic diagram of a typical blockchain network; [0022] FIG. 3 is a diagram about a relationship between subchains of a digital asset financial system borne by the blockchain network shown in FIG 2; [0023] FIG 4 is a schematic diagram of a reliability verification flow of a digital-asset data packet; and [0024] FIG.5 is a schematic diagram of forming a trusted tree in a transaction operation process of a data packet.

DETAILED DESCRIPTION OF THE EMBODIMENTS

[0025] To make objectives, technical solutions, and advantages of this application more clear, the technical solutions of this application are clearly and completely described below with reference to specific embodiments and corresponding accompanying drawings in this application. Obviously, the described embodiments are merely some embodiments of this application and are not all embodiments. According to the embodiments in this application, all other embodiments derived by persons of ordinary skills in the art without an effective effort fall within the protection scope of this application. The technical solutions provided in the embodiments of this application are described in detail below with reference to the accompanying drawings [0026] With development and applications of the Internet technology, digital assets, such as electronic currencies, Qcoin, online games, and some application software, emerge as required and are constantly applied in production and life of people, becoming an indispensable component in the Internet age. Various resources that are owned or controlled by enterprises or individuals, exist in a form of electronic data, and are valuable or are expected to be able to bring in economic benefits are all referred to as digital assets. The digital asset can be seen everywhere in life. For example, common expression forms of the digital asset include a movie ticket, a game equipment, a charging course, charging music, star voting, virtual points, and the like. The digital asset mainly relates to common the fields of literature, movie and television, games, animation, finance, and the like.

[0027] Packet is a data unit in TCP/IP protocol communication transmission, and generally is also referred to as "data packet". A digital-asset data packet refers to that a digital asset exists in the Internet in a form of a data packet. To ensure reliability, the digital-asset data packet usually takes a blockchain as a bearer network. However, the digital-asset data packet may generate a lot of process data during a transaction process. For example, in a blockchain network, a transaction is initiated to the digital-asset data packet by a node on a parent chain. A transaction operation process passes several subchains on the parent chain, and further passes next-level nodes of some nodes on the subchain. In other words, during a whole transaction process, the digital-asset data packet may pass a lot of terminal nodes, and may also generate a lot of process data. To ensure the reliability of the entire digital-asset data packet, all process data needs to be verified. A common method is a source tracing verification method. However, during the verification process, because a lot of blockchain service nodes are involved in the transaction process and a data volume is large, a lot of resources are wasted and efficiency is relatively low.

[0028] This application provides a reliability verification system for a digital-asset data packet, including several execution terminal nodes, several collection nodes, and several verification nodes, where the execution terminal node includes a plurality of nodes on different parent chains or subchains that perform operations to the digital-asset data packet. When a node in the blockchain performs a transaction operation to the digital-asset data packet (referred to as a data packet for short below), this node is an execution terminal node. Usually, a transaction operation of a data packet may pass a lot of nodes, and therefore there are correspondingly a lot of execution terminal nodes. The collection node is a node that is pre-imparted with a corresponding collection functional role. The collection node mainly collects various discrete signatures, and collects a plurality of signatures into one collective signature. The collection node may collect a plurality of signatures of a transaction or public keys and signatures of various participants of a multi-signature transaction into one public key and signature. The whole collection process is invisible, and verification is required for one time only. The verification node is a node that is pre-imparted with a corresponding verification functional role, and mainly verifies node reliability and signature reliability during the transaction process of the data packet. A node on the blockchain is what node depends on a functional role pre-imparted thereto. A node may be an execution terminal node, and may also be a collection node and a verification node. Quantities of the execution terminal nodes, the verification nodes, and the collection node are not defined. However, a plurality of verification nodes at least include one credible node. On this basis, a reliability verification request for the digital-asset data packet is initiated.

[0029] Refer to FIG 4 FIG 4 is a schematic diagram of a reliability verification flow of a digital-asset data packet. A reliability verification system for a digital-asset data packet in this application, wherein [0030] The verification node is configured to implement the following steps.

[0031] a verification request step: sending a reliability verification request for the digital-asset data packet to the execution terminal node; [0032] It should be noted that before the verification node initiates the reliability verification request to the execution terminal node, the execution terminal node further needs to perform a node reliability determining step. To be specific, the execution terminal node determines whether the verification node is a credible node. A specific determining manner is not specifically defined in this application. If the verification node is credible, the reliability verification request is received. To be specific, the verification node may verify reliability of the digital-asset data packet. If the verification node is not credible, for example, has a behavior that is not credible before, modifies data, or maliciously masquerade as a node, the execution terminal node refuses the reliability verification request of the verification node. In other words, the verification node cannot perform a reliability verification flow for the digital-asset data packet.

[0033] The execution terminal node is configured with: [0034] a verification receiving step: receiving the verification request sent by the verification node, where the verification request sent by the verification node is received if the execution terminal node determines that the verification node is a credible node; and [0035] a digital signing step: performing a digital signature to the data packet by using respective private keys of the execution terminal nodes, where there is at least one digital signature. An initial data packet may be allocated to one or more execution terminal nodes at beginning of a transaction, and the data packet may also be split and allocated to different execution terminal nodes. To ensure reliability of the execution terminal node, every transaction, and every section, the blockchain mainly uses the digital signature to achieve permission control.

For a data packet transaction of each execution terminal node, a private key of a respective execution terminal node is used to perform a digital signature, and a public key corresponding to the private key is made public. Performing the digital signature by using the private key has an anti-tamper mechanism, and may identify a legal identity of a transaction initiator, to prevent a malicious node from masquerading the identity, thus preventing the transaction from being tampered by a third party.

[0036] The digital signature is also referred to as an electronic signature, and achieves effects similar to those of a conventional physical signature through an algorithm. The digital signature processes signature content by using a relevant algorithm in the field of cryptography, to obtain a segment of characters used for representing a signature. In the field of cryptography, a digital signature algorithm generally includes a signature operation and a signature verification operation. After being signed, data only needs to be verified by using a matching signature verification method, and does not need to be identified through professional means as the convention physical signature.

[0037] The digital signature usually uses an asymmetric encryption algorithm. To be specific, each node needs a pair of keys of a private key and a public key. The private key is a key that can be owned by the owner only, and needs to be used while signing. Signatures of different private keys to a same segment of data are completely different, similar to handwriting of a physical signature. The digital signature usually is attached in an original message as additional information, to prove identity of a message sender. The public key is a key that can be obtained by all people, and needs to be used in signature verification. Because the public key can be obtained by all people, all nodes can verify legality of an identity.

[0038] Specific steps of the digital signature are as follows.

[0039] A digest generation step: generating digital digest for original data of the data packet through a hash calculation. In this application, original data of the digital-asset data packet is performed with a hash calculation, to generate digital digest.

[0040] A digest encryption step: encrypting the digital digest by using the private key of a node where the data packet is located, to obtain the digital signature. In this application, the generated digital digest is encrypted by using the private key of the execution terminal node where the data packet is located.

[0041] A digital signature sending step: sending the digital signature and the original data of the data packet to the verification node together.

[0042] The verification node is further configured with the following steps.

[0043] A digital signature verification step: verifying a digital signature result of the execution terminal node. A manner of verifying the digital signature is pre-negotiated and determined by the verification node and the execution terminal node; this is not specifically defined in this application.

[0044] A collection triggering step: if every digital signature passes the verification, triggering the collection node to collect the digital signature, to generate a collective signature. Signature collection is collecting a plurality of digital signature data of one or more execution terminal nodes to generate collective signature data corresponding to the execution terminal node. In other words, a plurality of signatures respectively signed to a plurality of messages by a plurality of users can be collected as a short signature.

[0045] The collection node is configured with: [0046] A signature collection step: collecting the digital signature, to generate a collective signature. The collective signature is a digital signature having additional properties, and has compression and batch processing properties. In actual work, a more advantageous factor is that the collective signature can be verified, and only needs to be verified for one time. To be specific, when collecting a plurality of digital signatures to generate a collective signature for the first time, all involved digital signatures and the collective signature after the digital signatures are collected need to be verified. Once a first verification is passed, during a subsequent verification, the digital signatures do not need to be verified, and only a collective signature result that is finally generated needs to be verified. A rule of the collective signature is that once the collective signature result passes the verification, it indicates that the various digital signatures that generate the collective signature all pass the verification.

[0047] The verification node is further configured with: [0048] a collective signature verification step: verifying the collective signature where if the verification is passed, it indicates that the data packet is credible.

[0049] The verification of the collective signature includes two cases. One is that all digital signatures involved in the collective signature are verified when the signature collection is performed for the first time; and the second is that the collective signature is verified when the collective signature is initialized. A specific case is as follow.

[0050] An initial verification step: all the digital signatures need to be verified when the collection node performs signature collection to the digital signatures for the first time. A verification manner of the digital signature may be predetermined. For example, a verification manner of the digital signature data may be that the digest information is encrypted by using the private key of the sender and is sent to a receiver together with source text, and the receiver decrypts the encrypted digest information by using an own public key, and then generates a piece of digest information for the received source text by using a HASH function, to be compared with the decrypted digest information. If the two are the same, it indicates that the received information is complete, and is not modified during a transmission process; or otherwise, it indicates that the information is modified. Therefore, the digital signature can verify completeness of information. It should be noted that all digital signature data is verified only when the signature collection is performed for the first time. After the first verification is passed, subsequently there is no need to verify all the digital signature data, and only a result of the collective signature needs to be verified.

[0051] A collection result verification step: during first signature collection, if all the digital signatures pass the verification, a first collective signature result is verified. Alternatively, in actual applications, an initial authentication needs to be performed, while the collective signature is being initialized. Initiation referred herein includes, for example, startup, system restart, or other cases of a system borne by a data packet transaction. A verification manner of the collective signature result may be predetermined by using the verification node. For example, the collective signature result may be a product of various digital signature data. Moreover, the verification node only needs to verify the collected signature for one time to confirm whether the digital signature involved in the collective signature comes from signatures of a designated execution terminal node respectively to the data packet and relevant attribute and links, thus significantly improving signature verification and transmission efficiencies. The collective signature result also may be another algorithm, that is defined by the user according to actual requirements; this is not specifically defined in this application.

[0052] Compared with a source tracing verification respectively to every digital signature, the collective signature only needs to pass the verification for one time, and therefore may greatly reduce costs of the signature verification. Moreover, because collecting a plurality of signatures as one signature, it may greatly save occupation of storage space of the execution terminal node, performing signature collection to the digital signature is aimed at providing an efficient reliability verification system for a digital-asset data packet that wastes few resources.

[0053] To more clearly record a transaction process of the data packet, the execution terminal node is further configured with the following steps.

[0054] A trusted tree generation step: generating a trusted tree of a processing process of the data packet according to a node level based on a transaction operation process of the execution terminal node to the data packet. The trusted tree herein refers to operation processes of all execution terminal nodes passed by the data packet. Refer to FIG. 5, FIG. 5 is a schematic diagram of forming a trusted tree in a transaction operation process of a data packet. In this embodiment, a manner of determining the node level is: first determining an execution terminal node that operates the data packet for the first time as a root node; and then determining a subnode in the manner of taking the root node as a level-1 node and taking a next-level node of the root node as a level-2 node. In combination with FIG 5, an execution terminal node of an original data packet is the root node. In this embodiment, if the original data packet is split into a data packet 0 and a data packet 1, the level-2 node has two execution terminal nodes that respectively operate the two grouping data packets. Similarly, a next-level node of the level-2 node is taken as a level-3 node, and the level-3 node further splits the data packet 0 into three data packets that respectively are data packet 01, data packet 02 and data packet 03, and further splits the data packet 1 into two data packets that respectively are data packet 11 and data packet 12. In other words, there are five corresponding level-3 nodes in FIG 5. Splitting is continued in this way until all execution terminal nodes passed by the data packet are recorded.

[0055] A trusted tree encryption step: encrypting each transaction operation in the trusted tree.

A specific encryption manner is not specifically defined in this application.

[0056] A trusted tree verification step: verifying the transaction operation of each execution terminal node, to determine whether there is a malicious operation.

[0057] A trusted tree storing step: if there is a malicious operation, recording an execution terminal node corresponding to the malicious operation; this indicates that an operation of the execution terminal node is untrusted. Subsequently, if there is a case in which the collective signature does not pass the verification, it probably is that a malicious node does not pass the verification. An encryption process and a verification process of each execution terminal node are recorded. The trusted tree is provisionally stored according to preset time. For example, the trusted tree may be stored after the transaction of the data packet is completed, or may be provisionally stored during a transaction process of the data packet; this may be preset according to a degree of complexity of the transaction of the data packet.

[0058] On the basis of the foregoing embodiments of generating the trusted tree, in this application, the digital signature may be further performed with signature collection based on the trusted tree. It should be noted that the signature collection may be performed to a plurality of digital signatures of one user, that is, one execution terminal node, or may be performed to a plurality of digital signatures of a plurality of users, that is, a plurality of execution terminal nodes, hi the trusted tree storing step, the execution terminal node corresponding to the malicious operation is already recorded, and the collective signature is constructed on the basis of the trusted tree. Once a case in which the collective signature does not pass the verification occurs, an execution terminal node having a record of a malicious operation needs to be searched first. In this way, one-by-one checking and source tracing are avoided, thus greatly improving efficiency. Meanwhile, a whole processing flow of the data packet may also be clearly displayed by using the trusted tree.

[0059] After the trusted tree records the whole transaction flow of the data packet, the verification node is further configured with the flowing steps.

[0060] A data packet storing step: storing the data packet at the verification node if the data packet is credible, that is, a verification result of the verification node for the collective signature is that the verification is passed. The data packet in this case is a credible data packet, and the stored data packet contains operations of a digital signature and a collective signature.

Specifically, the data packet storing step specifically includes the following steps.

[0061] A data packet splitting step: splitting the credible data packet to obtain a plurality of grouping data packets.

[0062] A grouping data packet encryption step: encrypting each grouping data packet.

[0063] An encrypted data packet storing step: storing each encrypted grouping data packet to the verification node, for subsequent use.

[0064] It may be learned from the foregoing technical solutions that this application provides a reliability verification system for a digital-asset data packet, including several execution terminal nodes, several collection nodes, and several verification nodes, where the execution terminal node includes a plurality of nodes on different parent chains or subchains that perform operations to the digital-asset data packet, the collection node is a node that is pre-imparted with a corresponding collection functional role, and the verification node is a node that is pre-imparted with a corresponding verification functional role. First, the verification node sends a reliability verification request for the digital-asset data packet to the execution terminal node.

The execution terminal node receives the verification request, and performs a digital signature to the data packet by using respective private key of the execution terminal nodes. The verification node verifies the digital signature, and triggers the collection node to collect the digital signature if every digital signature passes the verification. The collection node collects the digital signature, to generate a collective signature. The verification node verifies the collective signature result, and if the verification is passed, it indicates that the data packet is credible. Collecting signatures does not need to verify all digital signatures every time, and only needs to pass the verification for one time, thus greatly reducing costs in verifying the signature. Moreover, because collecting a plurality of signatures as one signature may greatly save occupation of storage space of the execution terminal node, an efficient reliability verification system for a digital-asset data packet that wastes few resources is provided. Meanwhile, the execution terminal node is further configured with the trusted tree generation step. Once a case in which the collective signature does not pass the verification occurs, the execution terminal node having a record of a malicious operation needs to be searched first. In this way, one-by-one checking and source tracing are avoided, thus greatly improving the efficiency.

Meanwhile, the whole processing flow of the data packet may also be clearly displayed by using the trusted tree.

Claims

Claims I A reliability verification system for a digital asset data packet, comprising several execution terminal nodes, several collection nodes, and several verification nodes, wherein the execution terminal node comprises a plurality of nodes on different parent chains or subchains that perform operations to the digital asset data packet, the collection node is a node that is pre-imparted with a corresponding collection functional role, and the verification node is a node that is pre-imparted with a corresponding verification functional role, wherein the verification node is configured with: a verification request step: sending a reliability verification request for the digital asset data packet to the execution terminal node; the execution terminal node is configured with: a verification receiving step: receiving the verification request sent by the verification node; a digital signing step: performing a digital signature to the data packet by using respective private keys of the execution terminal nodes, wherein there is at least one digital the verification node is further configured with: a digital signature verification step: verifying the digital signature; a collection triggering step: triggering the collection node to collect the digital signature if every digital signature passes the verification; the collection node is configured with: a signature collection step collecting the digital signature, to generate a collective signature; an initial verification step: verifying all the digital signatures when the collection node collects the digital signatures for the first time; and a collection result verification step: verifying a initial collective signature result if all the digital signatures pass the verification, wherein a verification manner of the collective signature result is pre-determined by the verification node the verification node is further configured with: a collective signature verification step: verifying the collective signature, wherein if the verification is passed, it indicates that the data packet is credible 2. The reliability verification system for a digital-asset data packet according to claim I, wherein the execution terminal node is further configured with: a node reliability determining step: determining whether the verification node is a credible node, receiving the reliability verification request if the verification node is credible, and refusing the reliability verification request if the verification node is not credible 3. The reliability verification system for a digital-asset data packet according to claim 1 or claim 2, wherein the execution terminal node is further configured with: a trusted tree generation step: generating a trusted tree of a processing process of the data packet according to a node level based on a transaction operation process of the execution terminal node for the data packet; a trusted tree encryption step: encrypting each transaction operation in the trusted tree; a trusted tree verification step: verifying each transaction operation, to determine whether there is a malicious operation; a trusted tree storing step: if there is a malicious operation, recording an execution terminal node corresponding to the malicious operation, and provisionally storing the trusted tree according to preset time.4. The reliability verification system for a digital-asset data packet according to claim 3, wherein the signature collection is performing signature collection to the digital signature based on the trusted tree.5. The reliability verification system for a digital-asset data packet according to claim 3 or claim 4, wherein a collection node determining step herein a collection node determining step comprises: a root node determining step: determining an execution terminal node that operates the data packet for the first time as a root node; a subnode determining step: taking the root node as a level-1 node, taking a next-level node level node of the root node as a level-2 node, and taking a next-level node of the level-2 node as a level-3 node, until all nodes passed by the data packet are recorded.6. The reliability verification system for a digital-asset data packet according to any preceding claim, wherein the digital signing specifically comprises: a digest generation step: generating digital digest for original] data of the data packet data through a hash calculation, a digest encryption step: encrypting the digital digest by using the private key of a node where the data packet is located, to obtain the digital signature; a digital signature sending step sending the digital signature and the original data of the data packet to the verification node together.7 The reliability verification system for a digital-asset data packet according to any preceding claim, wherein a mariner of verifying the digital signature is pre-negotiated and determined by the verification node and the execution terminal node.8. The reliability verification system for a digital-asset data packet according to any preceding claim, wherein the several verification nodes at least comprise one credible node.9. The reliability verification system for a digital-asset data packet according to any preceding claim, wherein the verification node is further configured with: a data packet storing step: if the data packet is credible, storing the data packet at the verification node, wherein the data packet storing step specifically comprises: a data packet splitting step: splitting credible data packet to obtain a plurality of grouping data packets; a grouping data packet encryption step: encrypting each grouping data packet; an encrypted data packet storing step: storing each encrypted grouping data packet to the verification node.