A method for constructing a trust data storage model in a peer-to-peer network

Abstract

The present invention discloses a method for constructing a peer-to-peer network trust data storage model, comprising establishing a blockchain TChain for trust data storage; constructing a verification and synchronization mechanism for inter-entity blockchains based on the established blockchain TChain; and algorithmically verifying the integrity, continuity, and legitimacy of the obtained blockchain TChain to obtain a final trust data storage model. By establishing a blockchain, constructing a blockchain synchronization mechanism, and further verifying its integrity, continuity, and legitimacy, the present invention obtains a peer-to-peer network trust data storage model based on blockchain, thereby preventing trust data from being tampered with, recovering lost data, and effectively reducing communication, time, and storage overhead.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and in particular to a method for constructing a peer-to-peer network trust data storage model. Background Art

[0002] With the increasing development of information technology, vast amounts of data are being acquired, stored, and interacted with. The effective use of data can bring convenience to our lives, and its application in various fields has in turn promoted the development of big data. However, while data provides us with high productivity, it also poses security issues. How can we ensure the trustworthiness of data storage?

[0003] Blockchain technology has the characteristics of decentralization, traceability and non-tamperability, which ensures the authenticity and credibility of stored data.

[0004] The shortcomings of the existing technology are that the trusted data in the current peer-to-peer network is easily lost and tampered with; and there are low communication efficiency between blocks and high time and storage overhead. Summary of the Invention

[0005] The purpose of the present invention is to overcome the deficiencies of the prior art. To achieve the above purpose, a method for constructing a peer-to-peer network trust data storage model is adopted to solve the problems raised in the above background technology.

[0006] A method for constructing a peer-to-peer network trust data storage model, comprising the following steps:

[0007] Step S1: Establishing a blockchain TChain for trust data storage;

[0008] Step S2: Constructing a verification and synchronization mechanism for inter-entity blockchains based on the established blockchain TChain;

[0009] Step S3: Perform algorithmic verification on the integrity, continuity, and legitimacy of the obtained blockchain TChain to obtain the final trust data storage model.

[0010] As a further solution of the present invention: the specific steps in step S1 include:

[0011] Define a trust data model: The trust data model consists of a five-tuple consisting of the set of all nodes participating in the interaction in the network, the interaction set of all interaction records in the network, the interaction set of all interaction moments in the network, a mapping function that maps interactions and interaction times to interacting nodes, and an evaluation function used to describe the node's satisfaction with the current interaction;

[0012] Define a sub-blockchain: Sort blocks by generation time, and use the chain formed by connecting blocks via hash values ​​as the user's sub-blockchain. The first block in the sub-blockchain is the genesis block, and any other block is a trust block. The trust block includes the predecessor block hash, trust data, and signature.

[0013] Define local consensus: The consensus reached by both parties on a block that complies with the preset rules is considered a local consensus.

[0014] Define an evaluation statistics graph: a graph describing the evaluation relationships between nodes and the number of node evaluations in a given blockchain or blockchain fragment is used as an evaluation statistics graph;

[0015] Define the main blockchain TChain: A blockchain that arranges all blocks in a two-dimensional manner according to their sub-blockchains and block generation time is used as the main blockchain TChain to record all trust data of all users in the network;

[0016] Through the growth of users and the maintenance of sub-blockchains, as each user's participation in evaluation increases, each user's sub-blockchains are entangled with each other to form a directed acyclic graph, generating the main blockchain TChain.

[0017] As a further solution of the present invention, the verification and synchronization mechanism of the blockchain between entities in step S2 is specifically as follows:

[0018] The local storage space of the blockchain TChain node is divided into a cache area and a confirmation area;

[0019] Obtain the sub-blockchain sequence of the synchronized node from the synchronized node, verify the integrity of the locally stored sub-blockchain, obtain the required blockchain fragment, and verify the continuity of the fragment;

[0020] Then save the continuous fragments to the cache area to verify the legitimacy of the blockchain fragment;

[0021] Finally, the passed blockchain fragment is saved in the confirmation area and the corresponding fragment is removed from the cache area.

[0022] As a further solution of the present invention: the specific steps of performing integrity verification according to the blockchain integrity verification algorithm in step S3 include:

[0023] First, verify whether the input blockchain is complete. If it is incomplete, return the missing block sequence;

[0024] Compare the sub-blockchain sequence of the node being synchronized with the sub-blockchain fragment stored locally on the node to be synchronized, and return the block sequence that needs to be synchronized from the node being synchronized.

[0025] As a further solution of the present invention: the specific steps of performing continuity verification according to the blockchain continuity verification algorithm in step S3 include:

[0026] Get the last block in the sub-blockchain fragment, extract the hash value of the predecessor block of the sub-blockchain recorded in the block, then calculate the hash value of the previous block, and compare the two block hash values ​​to see if they are equal;

[0027] If they are equal, move forward one block and continue the same steps until the continuity verification between the first block and the second block in the fragment is successful, which means that the block fragment is continuous; if they are different, it means that the obtained sub-blockchain fragment is discontinuous.

[0028] As a further solution of the present invention: the specific steps of performing legitimacy verification according to the blockchain legitimacy verification algorithm in step S3 include:

[0029] Update the sub-blockchain of the cache node to the latest version using the Integrity algorithm and the Continuity algorithm;

[0030] Determine whether a block exists in the sub-blockchains of both nodes that have reached consensus on the block;

[0031] If it exists, it means that the trust block is legal; if it does not exist, it means that the trust block is illegal.

[0032] Another technical solution: a peer-to-peer network trust data storage model, wherein the model is constructed using the method for constructing a peer-to-peer network trust data storage model;

[0033] The model consists of a physical layer, a synchronization layer, a data layer, a consensus layer, and trust data;

[0034] The physical layer divides the physical storage area of ​​the node into a buffer area and a confirmation area;

[0035] The synchronization layer verifies the blockchain according to the integrity verification algorithm, the continuity verification algorithm, and the legitimacy verification algorithm;

[0036] The data layer is used to encapsulate two data structures: the genesis block and the trust block.

[0037] As a further solution of the present invention: after the trust data is generated, a local consensus is reached at the consensus layer, blocks are generated at the data layer, the blocks are connected to generate the TChain sub-blockchain and the TChain main chain, and the block verification is completed at the synchronization layer through the integrity verification algorithm, continuity verification algorithm and legitimacy verification algorithm, and saved to the cache area or confirmation area of ​​the physical layer.

[0038] As a further solution of the present invention: the consensus layer and the data layer constitute the sub-blockchain TChain and the main blockchain TChain.

[0039] As a further solution of the present invention: the synchronization layer and the physical layer constitute the synchronization mechanism of the blockchain TChain.

[0040] Compared with the prior art, the present invention has the following technical effects:

[0041] Using the above technical solution, by constructing the TChain blockchain suitable for trust data storage, building the TChain blockchain synchronization mechanism for verification and synchronization of blockchains between entities, and designing blockchain integrity verification algorithms, blockchain continuity verification algorithms, and blockchain legitimacy verification algorithms. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] The specific embodiments of the present invention are described in detail below with reference to the accompanying drawings:

[0043] Figure 1 A schematic diagram of the steps of the method for constructing a storage model according to the embodiment disclosed in this application;

[0044] Figure 2 A schematic diagram of a trust block generated after evaluation is completed after node interaction in the embodiment disclosed in this application is completed;

[0045] Figure 3 For the embodiment disclosed in this application Figure 2 Schematic diagram of the "Tx" structure in the trust block;

[0046] Figure 4 This is a schematic diagram of the connection between the genesis block and the trust block in the embodiment disclosed in this application;

[0047] Figure 5 This is a schematic diagram of the process of nodes A and B reaching a local consensus in the embodiment disclosed in this application;

[0048] Figure 6 This is a schematic diagram of the structure of the TChain main chain of the embodiment disclosed in this application;

[0049] Figure 7 This is a schematic diagram of the structure of the evaluation statistics diagram of the embodiment disclosed in this application;

[0050] Figure 8 A schematic diagram of a block synchronization process according to an embodiment disclosed in this application;

[0051] Figure 9 This is a structural diagram of the trust data storage model TSMBB model of the embodiment disclosed in this application. DETAILED DESCRIPTION

[0052] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0053] Please refer to Figure 1 In an embodiment of the present invention, a method for constructing a peer-to-peer network trust data storage model comprises the following specific steps:

[0054] Step S1: Establishing the blockchain TChain for trust data storage. The specific steps include:

[0055] Since all nodes in a traditional blockchain network store and jointly maintain a global chain, it is not suitable for directly storing trust data. Therefore, it is necessary to establish a blockchain structure suitable for trust data storage, which is different from the traditional single-chain design of blockchain. In this embodiment, in this blockchain structure suitable for trust data storage, each user has a blockchain that records their own historical evaluations;

[0056] Step S11: Define the trust data model M = (P, I, T, a, w):

[0057] The trust data model consists of a five-tuple consisting of the set of all nodes participating in the interaction in the network, the interaction set of all interaction records in the network, the interaction set of all interaction moments in the network, a mapping function that maps the interaction and interaction time to the interaction node, and an evaluation function used to describe the node's satisfaction with the current interaction;

[0058] Specifically:

[0059] Node set P = {p1, p2, ..., p n}, the set of all nodes participating in the interaction in the network;

[0060] Interaction set I={i1,i2,…,i n}, the interaction set of all interaction records in the network;

[0061] Time set T={t1,t2,…,t n}, the time set of all interaction moments in the network;

[0062] Mapping function a: I×T→P×P, mapping interactions and interaction times to interaction nodes;

[0063] Evaluation function w: I×P→{-1,1} 1, which is used to describe the node's satisfaction with the interaction; if satisfied, output 1, indicating a positive evaluation; if dissatisfied, output -1, indicating a negative evaluation.

[0064] Step S12: Define sub-blockchains: Sort blocks by generation time, and use the chain formed by connecting blocks via hash values ​​as the user's sub-blockchain. The first block in the sub-blockchain is the genesis block, and any other block is a trust block. The trust block includes the predecessor block hash, trust data, and signature.

[0065] In this embodiment, the blockchain in which all blocks are arranged in two dimensions according to their sub-blockchains and block generation time is called the main blockchain TChain, or simply the main chain. The main chain records all trust data of all users in the network;

[0066] The many blocks generated by a user who participates in the trust evaluation are sorted according to the order of block generation time. The chain formed by connecting the blocks through hash values ​​is called the user's sub-blockchain, denoted by C i ;

[0067] Among them, C i .Block[n] represents the sub-blockchain C i The nth block of C i .Block[n] is C i .The successor block of Block[n-1], C i .Block[n-1] is C i .Block[n]'s predecessor block;

[0068] The first block in the child blockchain is taken as the genesis block, denoted as C i .Block[0]; Any block in the child blockchain except the genesis block is used as a trust block, denoted as C i .Block[j], j>0. The trust block consists of three parts: the predecessor block hash of the two parties, the trust data, and the signatures of the two parties.

[0069] like Figure 2 As shown in the figure, the trust block generated after the evaluation is completed after the interaction between nodes A and B is completed. A "The Hash value of the predecessor block of node A is stored in the position. If the predecessor block is the genesis block of A, the Hash value of the genesis block is stored. If the predecessor block is the trust block, the Hash value of the trust block is stored. "HASH BThe location of " stores the hash value of the predecessor block of node B. The trust data is recorded in the dotted box, and the arrow indicates the evaluation direction. The arrow points to the evaluation recipient, that is, "A" indicates the initiator of the evaluation and "B" indicates the recipient of the evaluation. Figure 3 As shown in the figure Figure 2 The diagram of the "Tx" structure mainly includes the interaction record Interaction, comment, and the timestamp of the time when the comment was generated.

[0070] Among them, "Sign A "Storage node A uses its own private key to trust data and the signature data of the two predecessor blocks, "Sign B In the block ", the storage node B uses its own private key to sign the trust data and the two predecessor blocks. The signing method is:

[0071] Sign i =SK i {hash||trust data||hash*}

[0072] A single TChain trust block contains only one piece of trust data. It's important to note that whether the arrow is unidirectional or bidirectional depends on the requirements of the upper-layer application. If the upper-layer application only performs a one-way evaluation at a time, the arrow is unidirectional. If the upper-layer application requires mutual evaluation between both parties, the arrow is bidirectional.

[0073] It can be seen that TChain's trust block is a structure with two input ports and two output ports. The input ports are connected to the predecessor blocks of the two evaluation participants, and the output ports are connected to the successor blocks of the participants, and the connection is made through the hash value of the block.

[0074] The genesis block in a child blockchain records the node's initial trust value and identity, serving as proof of the user's identity and uniqueness, and initializing trust. This means that each user has only one genesis block. When a new user joins the blockchain network, the network generates their genesis block, which serves as a credential for the node to join the network. This credential contains the user's identity information and initial trust value. The genesis block is block number 0, and the trust block is connected to it as block number 1. Subsequent trust blocks are numbered one at a time.

[0075] like Figure 4 As shown in the figure, it is a schematic diagram of the connection between the genesis block and the trust block, where A stores the hash value of the genesis block in the first trust block, thereby completing the block connection.

[0076] Step S13: Define local consensus: The common understanding of the block reached by both parties in accordance with the preset rules is regarded as the local consensus;

[0077] In this embodiment, if both parties meet the following conditions, a local consensus is reached. The definition rules are:

[0078] 1) Both parties acknowledge the evaluation;

[0079] 2) Sign the evaluation and generate a block;

[0080] 3) Add the blocks to their respective child blockchains.

[0081] If the two parties in the evaluation reach a consensus on a certain block, then the block can be found on the sub-blockchains of both parties; if a block only exists in one of the two parties in the evaluation, then one party must have violated the local consensus.

[0082] like Figure 5 As shown in the figure, it is a schematic diagram of the process of nodes A and B reaching a local consensus. Assume that the dotted line represents the block to be generated. The last block of the sub-blockchain CA of the evaluator A is the block in which C and A participate. The last block of the sub-blockchain CB of the evaluator B is the block in which B and D participate. The evaluation participants A and B give trust evaluations, calculate the hash value of the last block of their respective sub-blockchains, and calculate the signature Sign according to formula (1) A 、Sign B , the blocks are packaged and generated. The blocks are stored locally on A and B and added to the end of their respective sub-blockchains. At this point, A and B have reached a local consensus on the generation of this trust block. Therefore, if the two interacting parties reach a consensus on a certain evaluation, the trust block should be on both parties' sub-blockchains.

[0083] Step S14: Define an evaluation statistics graph: a graph describing the evaluation relationships between nodes and the number of node evaluations in a given blockchain or blockchain fragment is used as an evaluation statistics graph;

[0084] In this embodiment, the evaluation relationship between nodes and the number of node evaluations are combined according to the definition to obtain an evaluation statistical graph GM = (V, E, W). The evaluation statistical graph is composed of triples, specifically:

[0085] Vertex set: V:={v p :p∈P′}, the vertex in the evaluation statistics graph corresponds to the set of nodes P′ that generated a given blockchain or blockchain fragment;

[0086] A set of directed edges: Where I′ is the interaction record in a given blockchain or blockchain fragment, and T′ is the timestamp in a given blockchain or blockchain fragment.

[0087] Edge weight set: W((v p ,v q )):=|Ui∈I‘，t∈T’：a(i,)＝(,) w(i,p)|, where edge weight is the number of evaluations a node has for another node in a given blockchain or blockchain fragment.

[0088] In this embodiment, Figure 6 As shown in the figure, it is a schematic diagram of the main blockchain with A, B, C, D and E as 5 nodes; the main blockchain of the blockchain TChain in the figure is converted into an evaluation statistical chart. Figure 7 As shown in the figure, it is the evaluation statistics chart after transformation. There are five vertices in the figure, representing Figure 6 The five nodes A, B, C, D, and E in the main blockchain of the blockchain TChain are shown. There are directed edges between A and B, C, and D, indicating that A has evaluated B, C, and D. The weight of the directed edge from A to D is 2, indicating that A has evaluated D twice.

[0089] Step S15: Define the main blockchain TChain: A blockchain that arranges all blocks in two dimensions according to their sub-blockchains and block generation time is used as the main blockchain TChain, which is used to record all trust data of all users in the network;

[0090] Through the growth of users and the maintenance of sub-blockchains, as each user's participation in evaluation increases, each user's sub-blockchains are entangled with each other to form a directed acyclic graph, generating the main blockchain TChain.

[0091] In this embodiment, each participant in the TChain blockchain grows and maintains its own sub-blockchain. As participants contribute more, more blocks are created. From the perspective of the entire network, these sub-blockchains become entangled with the sub-blockchains of other participants, forming a directed acyclic graph (DAG) that forms the main TChain blockchain.

[0092] like Figure 6 As shown, take the main blockchain of 5 nodes A, B, C, D and E as an example. Figure 6 As shown in the figure, the predecessor block hash and node signature are hidden, and only the trust data is displayed. The five circular blocks A, B, C, D and E at the top represent the genesis blocks of the five nodes. The later the blocks are generated, the lower they are in the main chain. All blocks in the network are intertwined and arranged in two dimensions of sub-blockchains and generation time. For the entire network, there is actually a global and unique main blockchain.

[0093] Assume that there are N nodes in the network. The existing traditional blockchain is a single-chain structure with only one genesis block. The consensus mechanism enables all nodes in the network to reach a global consensus, thereby generating blocks and ensuring that the block data cannot be tampered with. The blocks record multiple transaction data, and all blocks are arranged in a one-dimensional manner according to the generation time.

[0094] In this embodiment, the blockchain TChain has a main blockchain and N sub-blockchains. Each sub-blockchain has a genesis block, so there are N genesis blocks in the network. Local consensus is reached between two nodes to generate a block. The user's sub-blockchains are intertwined to ensure that the block data cannot be tampered with. Each block records a trust data. The blocks in the main blockchain are arranged in two dimensions based on the block generation time and the participating parties.

[0095] As shown in Table 1 below, the table compares TChain blockchain with traditional blockchains;

[0096] Table 1 Comparison between TChain and traditional blockchains

[0097] Traditional blockchain TChain chain A main chain One main chain, N sub-chains Genesis Block one N Storing data Transaction data Trust Data Global consensus mechanism have none Reaching consensus Global consensus Local consensus Allow forks no yes Block characteristics Single Input Single Output Dual input and dual output Block granularity Multiple records A record Arrangement Time-based Two-dimensional arrangement based on time and user

[0098] Step S2: Constructing a verification and synchronization mechanism for inter-entity blockchains based on the established blockchain TChain;

[0099] Since trust data is stored in the child blockchain, when a node wants to perform a trust evaluation on another node, it needs to obtain the child blockchain of the node being evaluated and save the child blockchain of the node being evaluated locally. Verification and evaluation are performed through the synchronization mechanism of the blockchain TChain.

[0100] To be synchronized, a blockchain or blockchain fragment must meet three requirements: integrity, continuity, and legitimacy. Integrity means that the synchronized sub-blockchain is the longest chain of that sub-blockchain in the current network. Continuity means that every block in a blockchain or blockchain fragment, except the last one, can be linked to its successor through a hash value. Legitimacy means that every block in a blockchain or blockchain fragment can be found on the sub-blockchain of the other party that has reached partial consensus with it.

[0101] The synchronization mechanism of traditional blockchains is not suitable for TChain:

[0102] 1) To ensure that data cannot be tampered with, all nodes in the network store the entire blockchain redundantly, which takes up a lot of storage resources;

[0103] 2) The redundant storage process of nodes consumes a large amount of network transmission overhead;

[0104] 3) Nodes in a peer-to-peer network are all self-interested. Without incentives, nodes will not store data that is not related to themselves for no reason.

[0105] Therefore, it is necessary to establish a TChain blockchain synchronization mechanism.

[0106] In this embodiment, Figure 8 As shown in the figure, it is a schematic diagram of the TChain blockchain synchronization mechanism. The specific mechanism for building the verification and synchronization mechanism of the blockchain between entities is as follows:

[0107] The local storage space of the blockchain TChain node is divided into a cache area and a confirmation area;

[0108] Obtain the sub-blockchain sequence of the synchronized node from the synchronized node, verify the integrity of the locally stored sub-blockchain, obtain the required blockchain fragment, and verify the continuity of the fragment;

[0109] Then save the continuous fragments to the cache area to verify the legitimacy of the blockchain fragment;

[0110] Finally, the passed blockchain fragment is saved in the confirmation area and the corresponding fragment is removed from the cache area.

[0111] Subsequently, the blockchain integrity verification algorithm, blockchain continuity verification algorithm and blockchain legitimacy verification algorithm are used to verify the integrity, continuity and legitimacy of the blockchain to be synchronized.

[0112] Step S3: Perform algorithmic verification on the integrity, continuity, and legitimacy of the obtained blockchain TChain to obtain the final trust data storage model.

[0113] Step S31: According to the blockchain integrity verification algorithm Integrity (C p ) The specific steps for integrity verification include:

[0114] In this embodiment, the input blockchain is first verified to be complete. If it is incomplete, the missing block sequence is returned;

[0115] Compare the sub-blockchain sequence of the node being synchronized with the sub-blockchain fragment (including the cache area and confirmation area) stored locally on the node to be synchronized, and return the block sequence that needs to be synchronized from the node being synchronized.

[0116] In this embodiment, the blockchain integrity verification algorithm Integrity (C p ) is:

[0117]

[0118]

[0119] In this embodiment, in the first line of the integrity verification algorithm step, the locally stored sub-blockchain C is first read from the local cache area. p The sequence is recorded in array a[0:n], where a[0] is the first block number of the block fragment and a[n] is the last block number of the block fragment. In line 2, the child blockchain C is obtained from node p. p The block sequence is saved to b[0:m]. Since node p maintains the sub-blockchain C locally p , so the local sub-blockchain C of node p p Always Network Neutron Blockchain C p From line 3 to line 5, if the child blockchain C can be found in the cache p , and the last block number a[n] in the cache is the same as the latest block number b[m] obtained at node p, indicating that the current cache stores the longest chain of node p and there is no sequence that needs to be synchronized. At this time, the sub-blockchain C stored in the cache p The serial number interval of the blockchain fragment is [a[0], a[n]]. In lines 6 and 7, when C in the local cache p The sequence of C at node p p The sequences are not equal, indicating that the local storage is not the longest chain of node p, and the sequence to be synchronized is [a[n], b[m]]. From line 8 to line 13, if the sub-blockchain C does not exist in the cache, p , then search in the local confirmation area, if it can be found, the sub-blockchain C p The blockchain serial number is saved as c[0:k]. If the local confirmation area C p The sequence of C maintained locally by node p p If the sequences are equal, it means that the confirmation area stores the longest chain of node p and does not need to be updated; otherwise, the sequence that needs to be synchronized is [c[k],b[m]]. In lines 14 and 15, if there is no child blockchain C in the cache area and the confirmation area p , then get the entire sub-blockchain C from node p p .

[0120] The integrity verification algorithm obtains the node sub-blockchain C from the synchronization node p The longest sequence is compared with the sub-blockchain sequence stored locally by the synchronization node. From the two synchronizations, it can be seen that the sub-blockchain C stored by the synchronization node p The sequences are initially stored in the cache area, and some sequences are stored in the confirmation area after further verification. Obviously, when the cache area and the confirmation area have sub-blockchain C p When the fragment is generated, the last block number stored in the cache must be greater than the last block number in the confirmation area. Therefore, if there is a sub-blockchain C in the cache pIf there is no child blockchain C in the cache, the difference in block numbers is the block number that needs to be synchronized. p There are two possible situations: one is the sub-blockchain C p All are in the confirmation area; secondly, the synchronization node has never saved any C p If you can find C in the confirmation area p If it is the former, the block number that differs is the block number that needs to be synchronized; otherwise, it is the latter, and the entire C p .

[0121] The integrity verification algorithm mainly compares sequences. The time complexity of the algorithm is O(c), where c is a constant.

[0122] It returns the blockchain sequence that needs to be synchronized. The node to be synchronized then obtains the blockchain sequence fragment from the synchronized node and verifies the continuity of the fragment. This process is completed by the blockchain continuity verification algorithm.

[0123] Step S32: According to the blockchain continuity verification algorithm Continuity (C p , n+1,2n) to conduct continuity verification, including:

[0124] Get the last block in the sub-blockchain fragment, extract the hash value of the predecessor block of the sub-blockchain recorded in the block, then calculate the hash value of the previous block, and compare the two block hash values ​​to see if they are equal;

[0125] If they are equal, move forward one block and continue the same steps until the continuity verification between the first block and the second block in the fragment is successful, which means that the block fragment is continuous; if they are different, it means that the obtained sub-blockchain fragment is discontinuous.

[0126] In this embodiment, the blockchain continuity verification algorithm Continuity (C p , n+1,2n) is:

[0127]

[0128] In this embodiment, the input of the continuity verification algorithm is a sub-blockchain or sub-blockchain fragment whose continuity is to be verified, and the continuity of the fragment is verified in sequence from the end of the chain to the beginning of the chain. First, the last block in the sub-blockchain fragment is obtained, and the hash value of the predecessor block of the sub-blockchain recorded in the block is extracted. Then, the hash value of the previous block is calculated and compared to see if the two hash values ​​are equal. If they are equal, the algorithm moves forward one block and continues with the same steps until the continuity verification between the first and second blocks in the fragment is successful, indicating that the block fragment is continuous; if they are different, it means that the obtained sub-blockchain fragment is discontinuous. There are two cases where a sub-blockchain fragment is discontinuous:

[0129] 1) Block missing, manifested as discontinuous block sequence numbers in the blockchain fragment;

[0130] 2) The block is tampered with, which is manifested as the block sequence numbers of the blockchain fragments are continuous, but the block fragments are discontinuous.

[0131] The input of the algorithm is C p The algorithm performs hash operations on the fragment starting from the last block of the fragment and comparing adjacent blocks. Since fragments are finite, the algorithm is finite. The main operation of Algorithm 2 is the hash operation, which requires n operations, so the time complexity of the algorithm is O(n).

[0132] If the continuity verification algorithm obtains the sub-blockchain C p If the fragments of the child blockchain are continuous, the child blockchain fragments are saved to the cache area. At this point, the first synchronization and the first two verifications in the synchronization mechanism have been completed. p According to local consensus, if a block exists in the sub-blockchains of two nodes that have reached consensus on the block, then the block is legal.

[0133] According to the trust data model M = (P, I, T, a, w) and the evaluation statistics GM = (V, E, W), the sub-blockchain C of a given cache area p , then the sub-blockchain C in the cache area p The set of nodes that have evaluated with p is P q :={q:W9v p ,v q ))∨W(v p ,v q ))>0}, the set of evaluations that node q has participated in I q ={i∈I′:t∈T′,q∈a(i,t)}. Legal sub-blockchain C p The following relationship should be satisfied:

[0134]

[0135] Step S33: According to the blockchain legitimacy verification algorithm Validity (C p ) The specific steps for legality verification include:

[0136] Update the sub-blockchain of the cache node to the latest version using the Integrity algorithm and the Continuity algorithm;

[0137] Determine whether a block exists in the sub-blockchains of both nodes that have reached consensus on the block;

[0138] If it exists, it means that the trust block is legal; if it does not exist, it means that the trust block is illegal.

[0139] In this embodiment, the blockchain legitimacy verification algorithm Validity (C p ) is:

[0140]

[0141]

[0142] In this embodiment, the legitimacy verification algorithm verifies the sub-blockchain C in the cache area. p Are all the blocks in the fragment legal? Update the sub-blockchain of cache node q to the latest through the Integrity algorithm and Continuity algorithm. The set of interactions in which node p has q is I p′ , record each interaction i∈I p′ The mapping a(i, t) of q is compared with the mapping a(i′, t) of interaction in the sub-blockchain of q. If it exists, it means that the trust block is legal. If it does not exist, it means that the trust block is illegal. p′ The sets are all valid, indicating that the input C p The clip is legal.

[0143] In the C i While performing integrity verification, as can be seen from the second line of the legitimacy verification algorithm, the longest sub-blockchain of the relevant node will also be synchronized to the cache area. When this data is needed for the next synchronization, there is no need to download and verify it again, thus saving communication overhead and computing overhead.

[0144] It can be seen that in this mechanism, the node does not save the complete main chain locally, but only saves part of the main chain.

[0145] The functions used in the above three algorithms are explained as follows:

[0146] Hash(·): Calculates the hash value of the input item;

[0147] getHashInBlock(C p .Block[j]): Get the sub-blockchain C stored in the j-th block p hash;

[0148] getSeqFromNode(p): Get the sub-blockchain C from node p p sequence of the fragments;

[0149] getSeqFromBuffer(p): Get the sub-blockchain C from the local buffer p sequence of the fragments;

[0150] getSeqFromComfirm(p): Get sub-blockchain C from the local confirmation area p Sequence of fragments.

[0151] Another technical solution: a peer-to-peer network trust data storage model, wherein the model is constructed using any of the above-mentioned methods for constructing a peer-to-peer network trust data storage model;

[0152] In this embodiment, Figure 9 As shown, the diagram shows the trust data storage model TSMBB (Trust Storage Model Based Blockchain);

[0153] The model consists of a physical layer, a synchronization layer, a data layer, a consensus layer, and trust data;

[0154] The physical layer divides the physical storage area of ​​the node into a buffer area and a confirmation area;

[0155] The synchronization layer verifies the blockchain according to the integrity verification algorithm, the continuity verification algorithm, and the legitimacy verification algorithm;

[0156] The data layer is used to encapsulate two data structures: the genesis block and the trust block.

[0157] In this embodiment, after the trust data is generated, a local consensus is reached at the consensus layer, blocks are generated at the data layer, the blocks are connected to generate the TChain sub-blockchain and the TChain main chain, and the block verification is completed at the synchronization layer through the integrity verification algorithm, continuity verification algorithm and legitimacy verification algorithm, and saved to the cache area or confirmation area of ​​the physical layer.

[0158] In this embodiment, the consensus layer and the data layer constitute the sub-blockchain TChain and the main blockchain TChain.

[0159] In this embodiment, the synchronization layer and the physical layer constitute the synchronization mechanism of the blockchain TChain.

[0160] Although the embodiments of the present invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and variations may be made to these embodiments without departing from the principles and spirit of the present invention. The scope of the present invention is defined by the appended claims and their equivalents, and all should be included within the scope of protection of the present invention.

Claims

1. A method for constructing a peer-to-peer network trust data storage model, characterized in that: The specific steps include: Step S1: Establishing a blockchain TChain for trust data storage. The specific steps include: Define a trust data model: The trust data model consists of a five-tuple consisting of the set of all nodes participating in the interaction in the network, the interaction set of all interaction records in the network, the interaction set of all interaction moments in the network, a mapping function that maps interactions and interaction times to interacting nodes, and an evaluation function used to describe the node's satisfaction with the current interaction; Define a sub-blockchain: Sort blocks by their generation time, and use the chain formed by connecting blocks via hash values ​​as the user's sub-blockchain. The first block in the sub-blockchain is the genesis block, and any other block is a trust block. The trust block includes the predecessor block hash, trust data, and signature. Define local consensus: The consensus reached by both parties on a block that complies with the preset rules is considered a local consensus. Define an evaluation statistics graph: a graph describing the evaluation relationships between nodes and the number of node evaluations in a given blockchain or blockchain fragment is used as an evaluation statistics graph; Define the main blockchain TChain: A blockchain that arranges all blocks in a two-dimensional manner according to their sub-blockchains and block generation time is used as the main blockchain TChain to record all trust data of all users in the network; Through user growth and the maintenance of sub-blockchains, as each user participates in more evaluations, each user's sub-blockchains become entangled with each other, forming a directed acyclic graph, generating the main blockchain TChain; Step S2: Constructing a verification and synchronization mechanism for inter-entity blockchains based on the established blockchain TChain; Step S3: Perform algorithmic verification on the integrity, continuity, and legitimacy of the obtained blockchain TChain to obtain the final trust data storage model.

2. The method for constructing a peer-to-peer network trust data storage model according to claim 1, characterized in that: The specific verification and synchronization mechanism of the blockchain between entities in step S2 is as follows: The local storage space of the blockchain TChain node is divided into a cache area and a confirmation area; Obtain the sub-blockchain sequence of the synchronized node from the synchronized node, verify the integrity of the locally stored sub-blockchain, obtain the required blockchain fragment, and verify the continuity of the fragment; Then save the continuous fragments to the cache area to verify the legitimacy of the blockchain fragment; Finally, the passed blockchain fragment is saved in the confirmation area and the corresponding fragment is removed from the cache area.

3. The method for constructing a peer-to-peer network trust data storage model according to claim 1, characterized in that: The specific steps of performing integrity verification according to the blockchain integrity verification algorithm in step S3 include: First, verify whether the input blockchain is complete. If it is incomplete, return the missing block sequence; Compare the sub-blockchain sequence of the node being synchronized with the sub-blockchain fragment stored locally on the node to be synchronized, and return the block sequence that needs to be synchronized from the node being synchronized.

4. The method for constructing a peer-to-peer network trust data storage model according to claim 3, characterized in that: The specific steps of performing continuity verification according to the blockchain continuity verification algorithm in step S3 include: Get the last block in the sub-blockchain fragment, extract the hash value of the predecessor block of the sub-blockchain recorded in the block, then calculate the hash value of the previous block, and compare the two block hash values ​​to see if they are equal; If they are equal, move forward one block and continue the same steps until the continuity verification between the first block and the second block in the fragment is successful, which means that the block fragment is continuous; if they are different, it means that the obtained sub-blockchain fragment is discontinuous.

5. The method for constructing a peer-to-peer network trust data storage model according to claim 4, characterized in that: The specific steps of performing the legitimacy verification according to the blockchain legitimacy verification algorithm in step S3 include: Update the sub-blockchain of the cache node to the latest version using the Integrity algorithm and the Continuity algorithm; Determine whether a block exists in the sub-blockchains of both nodes that have reached consensus on the block; If it exists, it means that the trust block is legal; if it does not exist, it means that the trust block is illegal.

6. A peer-to-peer network trust data storage model, characterized in that: The model is constructed using the method for constructing a peer-to-peer network trust data storage model according to any one of claims 1 to 5; The model consists of a physical layer, a synchronization layer, a data layer, a consensus layer, and trust data; The physical layer divides the physical storage area of ​​the node into a buffer area and a confirmation area; The synchronization layer verifies the blockchain according to the integrity verification algorithm, the continuity verification algorithm, and the legitimacy verification algorithm; The data layer is used to encapsulate two data structures: the genesis block and the trust block.

7. A peer-to-peer network trust data storage model according to claim 6, characterized in that: After the trust data is generated, a local consensus is reached at the consensus layer, blocks are generated at the data layer, and the blocks are connected to generate the TChain sub-blockchain and the TChain main chain. Block verification is completed at the synchronization layer through the integrity verification algorithm, continuity verification algorithm, and legitimacy verification algorithm, and the blocks are saved to the cache area or confirmation area of ​​the physical layer.

8. A peer-to-peer network trust data storage model according to claim 6, characterized in that: The consensus layer and data layer constitute the sub-blockchain TChain and the main blockchain TChain.

9. A peer-to-peer network trust data storage model according to claim 6, characterized in that: The synchronization layer and the physical layer constitute the synchronization mechanism of the blockchain TChain.

Images