A block generation method, device and system based on DAG multi-node consensus

Abstract

The application provides a block generation method, device and system based on DAG multi-node consensus, comprising: receiving a transaction request submitted by a user on a client; determining a generated block set at a current time, wherein the current time is the time of receiving the transaction request; in response to determining that the transaction request satisfies a Poisson distribution, determining a candidate to-be-generated block set; selecting a generated block from the generated block set and a candidate to-be-generated block from the candidate to-be-generated block set, verifying the transaction request in the generated block and the transaction request in the candidate to-be-generated block; in response to successful verification, updating the node weight of the generated block, and adding the candidate to-be-generated block as a target to-be-generated block to the DAG network. The technical scheme of the application replaces the mode of competing to confirm a leader node, reduces the time delay and performance bottleneck of selecting a leader node, effectively replaces the existing single-chain structure, and improves the expansibility of the chain structure.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of blockchains, and in particular relates to a block generation method, device and system based on DAG multi-node consensus. BACKGROUND

[0002] As a relatively mature blockchain consensus model, the blockchain consensus computing technology has been widely applied to blockchain transaction systems in environments where the transaction response speed requirement is not high and the transaction volume is moderate.

[0003] In the prior art, the blockchain network selects a leader node (Leader) through competition and publishes a verified transaction through the Leader, which has the problems of low concurrency, poor scalability, and high transaction cost, in particular: only one leader node signs transactions at each time point, and other nodes verify them, which reduces the efficiency of a large number of transaction concurrent executions; the blockchain is a single-chain structure and can only increase transaction blocks in one direction, which leads to poor scalability and inability of other authenticated transactions to be accessed; in order to obtain faster execution, each transaction needs to be priced through a transaction fee, which increases the cost of transaction execution and causes the transaction parties to pay a high price. SUMMARY

[0004] To solve the problems in the prior art, the present application provides a block generation method, device and system based on DAG multi-node consensus, which can solve the problems of low efficiency, poor scalability, and high transaction cost of multi-node consensus.

[0005] According to a first aspect of the present application, a block generation method based on DAG multi-node consensus is provided, comprising:

[0006] receiving a transaction request submitted by a user on a client;

[0007] determining a set of generated blocks of a DAG network at a current time, wherein the current time is the time when the transaction request is received;

[0008] in response to determining that the transaction request satisfies a Poisson distribution, determining a set of candidate to-be-generated blocks;

[0009] selecting a generated block from the set of generated blocks and selecting a candidate to-be-generated block from the set of candidate to-be-generated blocks, and verifying the transaction requests in the generated block and the candidate to-be-generated block;

[0010] in response to determining that the verification is successful, updating the node weight of the generated block, and adding the candidate to-be-generated block as a target to-be-generated block to the DAG network.

[0011] In some optional modes of the present embodiment, in response to determining that the transaction request satisfies the Poisson distribution, determining a candidate block set to be generated includes:

[0012] In response to determining that the transaction request satisfies the Poisson distribution, determining a block generation rate of the DAG network within a preset time period, wherein the preset time period is an average execution time required for the consensus node to issue a transaction request;

[0013] According to the block generation rate, the average execution time and the transaction request, determining a candidate block set to be generated.

[0014] In some optional modes of the present embodiment, in response to determining that the transaction request satisfies the Poisson distribution, determining a block generation rate of the DAG network within a preset time period includes:

[0015] In response to determining that the transaction request satisfies the Poisson distribution, determining a probability distribution of the number of potential transactions in the transaction request within the average execution time;

[0016] According to the probability distribution, determining a block generation rate of the DAG network within the average execution time.

[0017] In some optional modes of the present embodiment, according to the block generation rate, the average execution time and the transaction request, determining a candidate block set to be generated includes:

[0018] Determining the number of identifications of the candidate block to be generated to the transaction request;

[0019] In response to determining that the number of identifications is 2, the number of blocks in the candidate block set to be generated satisfies:

[0020] L0=2λh

[0021] In response to determining that the number of identifications is greater than 2, the number of blocks in the candidate block set to be generated satisfies:

[0022]

[0023] Wherein, the L0 is the number of blocks in the candidate block set to be generated when the number of identifications is 2; the is the number of blocks in the candidate block set to be generated when the number of identifications is k; the λ is the block generation rate; h is the average execution time of the consensus node to issue a transaction request.

[0024] In some optional modes of the present embodiment, updating the node weight of the generated block includes:

[0025] Determining an initial weight of the generated block in the DAG network;

[0026] determining a transaction weight of all transaction requests in the target to-be-generated block;

[0027] updating the node weight as a sum of the initial weight and the transaction weight.

[0028] In some optional manners of the embodiment, the adding the candidate to-be-generated block as the target to-be-generated block into the DAG network comprises:

[0029] establishing a partial order relation between the generated block and the target to-be-generated block;

[0030] adding the target to-be-generated block into the DAG network according to the partial order relation.

[0031] In some optional manners of the embodiment, the method further comprises a step of initializing security parameters:

[0032] inputting a user public key and a distributed digital identity to call a blockchain smart contract interface to initialize security parameters, to generate a digital identity and a symmetric key;

[0033] notarizing and encrypting the digital identity, the master key and the user public key, and generating the security parameters by encrypting the symmetric key;

[0034] returning the security parameters to a client.

[0035] According to a second aspect of the application, a corresponding block generation device based on DAG multi-node consensus is also provided, comprising:

[0036] a receiving module configured to receive a transaction request submitted by a user on a client;

[0037] a generated block determination module configured to determine a generated block set of the DAG network at a current time, wherein the current time is a time when the transaction request is received;

[0038] a candidate to-be-generated block determination module configured to determine a candidate to-be-generated block set in response to determining that the transaction request satisfies a Poisson distribution;

[0039] a verification module configured to select one generated block from the generated block set and select one candidate to-be-generated block from the candidate to-be-generated block set, and verify transaction requests in the generated block and the candidate to-be-generated block;

[0040] a block generation module configured to update a node weight of the generated block in response to determining that the verification is successful, and add the candidate to-be-generated block as a target to-be-generated block into the DAG network.

[0041] According to a third aspect of the present application, a block generation system based on DAG multi-node consensus is also provided, comprising a client, a service gateway, a storage node, and a blockchain node;

[0042] The client is in communication connection with the service gateway, the service gateway is in communication connection with the storage node cluster, and the storage node cluster is in communication connection with the blockchain node cluster;

[0043] The client initiates a smart contract deployment request, a distributed storage transaction request, and a distributed storage query request;

[0044] The service gateway provides a smart contract API, implements flow limiting and fusing, security detection, file storage and access, identity authentication, and security parameter setting;

[0045] The storage node receives a file read / write request of the service gateway, performs distributed file read / write, and stores transaction information to the blockchain node;

[0046] The blockchain node is configured to execute the block generation method based on DAG multi-node consensus of the preceding embodiments, complete transaction broadcasting, transaction execution, transaction verification, consensus, and storage.

[0047] According to a fourth aspect of the present application, an electronic device is also provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to realize the steps of the block generation method based on DAG multi-node consensus.

[0048] According to a fifth aspect of the present application, a computer readable storage medium is also provided, which stores a computer program executable on a processor to realize the steps of the block generation method based on DAG multi-node consensus.

[0049] According to a sixth aspect of the present application, a computer program product is also provided, comprising computer program / instructions executable on a processor to realize the steps of the block generation method based on DAG multi-node consensus.

[0050] The application establishes a set of DAG-based multi-node consensus computing system and method for solving the consistency and expansibility of multi-node consensus, which is based on directed acyclic graph, constructs a tree graph structure of multi-node consensus computing, and establishes a set of DAG-based on-chain and off-chain data real evaluation method, which takes the weight of the recognized transaction as the evaluation standard, the more consensus nodes that recognize the transaction, the greater the transaction credibility, and realizes content verification in the increased nodes, and realizes effective evaluation of transaction authenticity. The method is suitable for multi-node consensus computing in a decentralized environment, effectively solves the low efficiency, poor expansibility and high transaction cost of multi-node consensus, and has good popularization value. BRIEF DESCRIPTION OF DRAWINGS

[0051] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained without creative labor on the basis of these drawings.

[0052] Figure 1 A block generation method based on DAG multi-node consensus provided by the present application is shown in the scene structure diagram.

[0053] Figure 2 A hierarchical structure diagram of the block generation method based on DAG multi-node consensus provided by the present application.

[0054] Figure 3 A service gateway structure diagram of the block generation system based on DAG multi-node consensus provided by the present application.

[0055] Figure 4 A block chain node structure diagram of the block generation system based on DAG multi-node consensus provided by the present application.

[0056] Figure 5 A DS node structure diagram of the block generation system based on DAG multi-node consensus provided by the present application.

[0057] Figure 6 A flowchart of the block generation method based on DAG multi-node consensus provided by the embodiment of the present application.

[0058] Figure 7 An interaction schematic diagram of the block generation method based on DAG multi-node consensus provided by another embodiment of the present application.

[0059] Figure 8A schematic diagram of a block generation device based on DAG multi-node consensus provided by an embodiment of the present application.

[0060] Figure 9 A block diagram of an electronic device for implementing a block generation method based on DAG multi-node consensus according to an embodiment of the present application. DETAILED DESCRIPTION

[0061] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of protection of the present application.

[0062] Based on the problems in the background art, the present application provides a block generation system based on DAG multi-node consensus, comprising a client, a service gateway, a storage node, and a blockchain node, wherein:

[0063] The client is in communication connection with the service gateway, the service gateway is in communication connection with the storage node cluster, and the storage node cluster is in communication connection with the blockchain node cluster.

[0064] The client initiates a smart contract deployment request, a distributed storage transaction request, and a distributed storage query request.

[0065] The service gateway provides a smart contract API, implements flow limiting and fusing, security detection, file storage and access, identity authentication, and security parameter setting.

[0066] The storage node receives a file read / write request of the service gateway, performs distributed file read / write, and stores transaction information to the blockchain node.

[0067] The blockchain node is configured to execute a block generation method based on DAG multi-node consensus according to an embodiment of the present application to complete transaction broadcasting, transaction execution, transaction verification, consensus, and storage.

[0068] In a specific embodiment, as shown in Figure 1 FIG. 1 is a structural diagram of a block generation system based on DAG multi-node consensus, comprising a user A (user B) 1, a client A (client B) 2, a service gateway 3, a blockchain node 4, and a storage node (DS node) 5, wherein:

[0069] The user A (user B) 1 initiates user data upload or receives data information from a blockchain network, and the user hopes that sensitive information cannot be leaked.

[0070] Client A (Client B) 2: mainly responsible for receiving user's transaction request, initiating smart contract deployment request, distributed storage transaction request, distributed storage query request, etc.

[0071] Service gateway A (service gateway B) 3: mainly responsible for providing smart contract API, realizing flow limiting and fusing, security detection, file storage and access, identity authentication and security parameter setting, etc.

[0072] Blockchain node 4: a node that completes transaction broadcast, transaction execution, transaction verification, consensus and storage, etc. It has the general characteristics of blockchain. Through the client, file reading instructions are initiated, and after the execution of the file read-write storage evidence smart contract, the transaction record is also saved on the blockchain.

[0073] Storage node 5: that is, a decentralized DS node, responsible for receiving file read-write requests of service gateway 3, performing distributed file read-write, and storing transaction information into blockchain node. The client A and client B of the application respectively access the blockchain node through the service gateway A and service gateway B, realize publishing smart contract, reading file and storing file.

[0074] Based on the above system, in a specific embodiment, the hierarchical structure diagram of the block generation system based on DAG multi-node consensus is as shown in Figure 2 , which includes a client access layer 20, a service gateway layer 21, a blockchain network 22, and a decentralized file storage network 23, wherein:

[0075] Client access layer 20: responsible for providing operator access client software, facilitating to initiate distributed storage request and receive distributed storage result. The client can publish chain code on the blockchain platform, and after the client generates behavior data uploaded or downloaded, the chain code can be called to initiate transaction request, chain the behavior data, according to the client use scene, submit to the corresponding channel of each scene (the client can directly send the client behavior data without processing, and the specific data processing logic can be executed by the scene provider). The supplier can also publish chain code, which can query the data belonging to its own channel and process and analyze the data of its own channel.

[0076] Service gateway layer 21: responsible for providing blockchain smart contract service API to the client, realizing flow limiting and fusing of transaction, file uploading and downloading of DS node, CID generation, realizing DID registration, verification, directory query update and other smart contract function calls.

[0077] Blockchain network 22: responsible for receiving and decrypting file decentralized storage messages, triggering preset smart contract logic, and forming decentralized storage log results. The blockchain network can provide hosting nodes, and local node deployment can also be provided for capable providers. Each scenario provider has its own channel on the blockchain, and scenario providers cannot access the data information of other channels, i.e., other providers.

[0078] Decentralized file storage network 23: responsible for submitting upload (download), query, and other requests submitted by the client, configuring parameters, data, and business logic through decentralized storage logic, and encrypting file block data, the hash value of which is broadcast to the blockchain network 22. Scenario providers can also publish joint operation chain code, and call DS node services through the chain code. Each blockchain node has a corresponding DS node service, and the chain code can specify which DS services need to be jointly calculated. Scenario providers initiate joint calculation requests through the chain code, and the data of other channels of the providers cannot be accessed by each other, and DS can perform decentralized data storage without leaking each other's data.

[0079] Specifically, as shown in Figure 3 , the service gateway structure in the system includes a communication module 31, a flow limiting and fusing module 32, a security authentication module 33, and an API service interface 34.

[0080] Communication module 31: responsible for establishing a secure channel for the service gateway, implementing decentralized file storage request, initializing security parameters, and other message transmission.

[0081] Flow limiting and fusing module 32: responsible for transaction flow limiting and fusing control according to transaction throughput configuration.

[0082] Security authentication module 33: responsible for storing user private keys and symmetric keys, managing user digital identity DID; responsible for calling security interface API provided by the blockchain network, realizing user identity registration, authentication, and encryption and decryption of encrypted files.

[0083] API service interface 34: responsible for providing blockchain smart contract API calls, such as data notarization, information query, security settings, and a series of smart contract API interface services.

[0084] Specifically, as shown in Figure 4 , the blockchain node structure in the system includes a communication module 41, a smart contract module 42, a consensus verification module 43, and a block generation module 44.

[0085] Communication module 41: responsible for communication and interaction between nodes, completing general blockchain node communication information, including transaction information broadcast, consensus-related information, block synchronization information, network state information, etc.

[0086] The smart contract module 42 is responsible for receiving the transaction request from the communication module 41, generating a unique transaction identifier, assembling the transaction unique identifier, contract unique identifier and calling parameters into a transaction, and broadcasting to other nodes of the blockchain; at the same time, the smart contract is compiled through the built-in compiler to realize the execution of the transaction request. The smart contract module of the present application provides data storage service, and stores the smart contract execution result in the form of a file in the blockchain storage node.

[0087] The smart contract transaction u is issued by the consensus node, and is formally represented as:

[0088] u=(w(u),w orign (u),From,to,Amount,signNode,timestamp,sign)

[0089] Wherein, w(u) represents the cumulative weight of u, w orign (u) represents the weight of u itself, and formally, for a given transaction u∈N, the node weight is represented as w(u), and the formal representation is:

[0090]

[0091] Wherein represents the weight of transaction v, w orign (u) represents the weight of u itself. From represents the initial account, to represents the target account, Amount represents the transaction amount, signNode represents the node that issues u, timestamp represents the timestamp, and sign represents the signature of u.

[0092] The consensus verification module 43 is responsible for consensus processing on the received transaction request, such as reaching a consensus, calling the smart contract module 53, executing the smart contract, and finally forming a record for future audit traceability or verification.

[0093] The block generation module 44 is used to generate a DAG-based block form, and the block x is formally represented as:

[0094] x=({e1(u),...,e k (u)},trans,timestamp,signNode,sign)

[0095] Wherein, e(u) represents the node that directly or indirectly recognizes the transaction u, if the node is y, e(u) is represented as: (r(u) y , intv), wherein r(u) y =sign y (u); that is, the node y that signs the transaction u, and intv is an integer value for indicating the reference or voting type.

[0096] Specifically, as shown in Figure 5 the storage node structure in the system includes a communication module 51, a content generation module 52, a DAG module 53, and a Chunk module 54, wherein:

[0097] The communication module 51 is responsible for establishing a secure channel for the DS node and realizing the sending and receiving of distributed storage messages.

[0098] The content generation module 52 is responsible for processing the content identifier (Cid) of the decentralized file content. Let M represent the file content of the user, and Cid be the content identifier of M.

[0099] The DAG module 53 is responsible for performing Merkle verification on the content address Cid to ensure that the Cid of the root node is equal to the calculated summary hash.

[0100] The Chunk module 54 is responsible for splitting the file object data content and ensuring that the split data is connected to each other to form a file object tree.

[0101] Based on the DAG multi-node consensus block generation system as shown in Figures 1 to 5 , the present application also provides a DAG multi-node consensus-based block generation method, taking a blockchain node as an execution subject, as shown in Figure 6 , comprising:

[0102] S601, receiving a transaction request submitted by a user on a client.

[0103] In this embodiment, the smart contract module in the blockchain node is used to receive the transaction request submitted by the user on the client, which is prior art and will not be described in detail herein.

[0104] S602, determining a generated block set of the DAG network at a current time, wherein the current time is the time of receiving the transaction request.

[0105] It should be understood that the DAG network is a directed acyclic graph network, wherein the directed acyclic graph G is formally represented as G=(V,E), V represents a set of points, E represents a set of edges, the reachability of G can be represented by the partial order relation < of its vertices, and if (u,v)∈E, there is a path from vertex u to vertex v, and their partial order relation can be written as u

[0106] The blocks in this embodiment are connected in the form of DAG, and the time of receiving the transaction request is the current time, at which the generated block set of the DAG network at the current time can be determined.

[0107] S603, in response to determining that the transaction request satisfies the Poisson distribution, determining a candidate block set to be generated.

[0108] In this embodiment, the consensus verification module in the blockchain node is responsible for consensus processing on the received transaction request, such as reaching a consensus, calling the smart contract module, executing the smart contract, and finally recording for future audit traceability or verification.

[0109] The present application adopts node weight distribution consensus, which allocates node weight w (w>0) to each consensus node, w can be positively correlated with equity currency, in the consensus process, there is no leader node to update the ledger state, but allows the consensus node to select 2 Tips (blocks) for verification, if the verification is successful, the consensus node votes for the Tip, and the new transaction is established on the recognition of the Tip, forming a partial order. In order to reduce the number of Tips and maintain it within a relatively stable value range, it is assumed that the potential transaction request presents Poisson distribution at time t, that is, the probability distribution L(t) of transaction data occurring in the interval [t, t+h] is expressed as:

[0110]

[0111] Obviously, the condition for L(t) to present positive recursion is that P[L(t)=k] exists when t→∞, and the value is positive for all k≥1. In order to ensure that the number of Tips oscillates within a stable interval, let λ represent the Poisson distribution rate, that is, the block generation rate, t is the current time when the transaction request is received, h represents the average execution time of node transaction, and the block generation rate is the number of blocks that can be generated per unit time.

[0112] In a specific embodiment, in response to determining that the transaction request satisfies the Poisson distribution, the candidate block set to be generated is determined, further comprising:

[0113] S6031, in response to determining that the transaction request satisfies the Poisson distribution, determining the block generation rate of the DAG network within a preset time period, wherein the preset time period is the average execution time required by the consensus node to issue the transaction request.

[0114] In some optional modes of this embodiment, when it is determined that the transaction request satisfies the Poisson distribution, the probability distribution of the number of potential transactions in the transaction request within the average execution time is determined.

[0115] According to the probability distribution, the block generation rate of the DAG network within the average execution time is determined.

[0116] For example, in order to reduce the number of Tips and maintain it in a relatively stable value range, it is assumed that the potential transaction request is in Poisson distribution at time t, that is, the probability distribution L(t) of transaction data occurring in the interval [t, t+h] is represented as:

[0117]

[0118] Obviously, the condition for L(t) to be positive recursive is that P[L(t) = k] exists as t→∞, and the value is positive for all k≥1. In order to ensure that the number of Tips fluctuates in a stable interval, let λ represent the Poisson distribution rate, that is, the block generation rate, t is the current time when the transaction request is received, h represents the average execution time of the node issuing the transaction, and the block generation rate is the number of blocks that can be generated per unit time.

[0119] S6032, determining a candidate block set to be generated according to the block generation rate, the average execution time, and the transaction request.

[0120] That is, when the transaction request satisfies the Poisson distribution, the average execution time required by the consensus node to issue the transaction request is determined by the block generation rate, and the candidate block set to be generated is determined in combination with the transaction request. It should be noted that the candidate block set to be generated is a block that has not been identified and included in the DAG network, but can be discovered by the consensus node.

[0121] In a specific embodiment, the number of blocks in the candidate block set to be generated is related to the number of identifications of the transaction request by the candidate block to be generated, so that the candidate block set to be generated is determined according to the block generation rate, the average execution time, and the transaction request, further comprising:

[0122] determining the number of identifications of the transaction request by the candidate block to be generated;

[0123] in response to determining that the number of identifications is 2, the number of blocks in the candidate block set to be generated satisfies:

[0124] L0=2λh>0

[0125] wherein the L0 is the number of blocks in the candidate block set to be generated when the number of identifications is 2, that is, the number of candidate block sets to be generated (implicit Tips) at time t is 2λh.

[0126] in response to determining that the number of identifications is greater than 2, the number of blocks in the candidate block set to be generated satisfies:

[0127]

[0128] wherein the When the number of identifications is s, the new block identifies s transactions instead of 2 transactions, where s is greater than 2, the number of blocks in the candidate block set to be generated; the lambda is the block generation rate; and h is the average execution time of the consensus node to issue a transaction request.

[0129] S604, selecting one generated block from the generated block set and one candidate block to be generated from the candidate block set to be generated, and verifying the transaction requests in the generated block and the transaction requests in the candidate block to be generated.

[0130] In this embodiment, the number of blocks in the generated block set is multiple, and the number of blocks in the candidate block set to be generated is multiple, so that one generated block is randomly selected from the leaf block of the generated block set of the DAG network, one candidate block to be generated is randomly selected from the candidate block set to be generated, and the transaction requests in the generated block and the transaction requests in the candidate block to be generated are verified, wherein the blocks in the candidate block set to be generated are implicit blocks that have not been added to the DAG network, and the blocks in the generated block set are explicit blocks that have been added to the DAG network.

[0131] S605, in response to determining that the verification is successful, updating the node weight of the generated block, and adding the candidate block to be generated as a target block to be generated to the DAG network.

[0132] In this embodiment, in response to determining that the verification is successful, the node weight of the generated block is updated, and the candidate block to be generated is added as a target block to be generated to the DAG network.

[0133] In a specific embodiment, let u be an explicit block and v be an implicit block, execute transactions trans(u) and trans(v), when the transactions in blocks u and v are verified successfully, update the node weight of the generated block by taking the implicit block v as a target block to be generated, including:

[0134] determining the initial weight of the generated block in the DAG network; determining the transaction weight of all transaction requests in the target block to be generated; updating the node weight as the sum of the initial weight and the transaction weight, specifically, satisfying the following formula:

[0135]

[0136] wherein w(u) represents the cumulative weight of block u, w orign (u) represents the initial weight of block u itself, represents the transaction weight of all transaction requests in the target block to be generated.

[0137] Generally, the credibility of a transaction is evaluated by a transaction weight, and the greater the transaction weight indicates the higher degree of recognition by consensus nodes, wherein u1, u2∈N, if w(u1)<w(u2), it means that the credibility of u1 is less than that of u2, and vice versa.

[0138] In a specific embodiment, the method further comprises: establishing a partial order relationship between the generated block and the target block to be generated; and adding the target block to be generated into the DAG network according to the partial order relationship.

[0139] That is, a new block v is created, and a DAG edge is added, so that the block u points to the block v, that is:

[0140] x=({e1(u),...,e k (u)},trans,timestamp,signNode,sign)

[0141] Wherein, e(u) represents a node that directly or indirectly recognizes the transaction u, if the node is y, then e(u) is represented as: (r(u) y ,intv), wherein r(u) y =sign y (u); that is, the node y that signs the transaction u, and intv is an integer value for indicating a reference or voting type.

[0142] In a specific embodiment, if the transaction request verification in the two blocks is not successful, for example, if at least one transaction verification in trans(u), trans(v) fails, then w(u) is not updated, and the new block is not created.

[0143] Based on the DAG multi-node consensus-based block generation method of the foregoing embodiment, the target block to be generated can be finally obtained as follows:

[0144] Let x∈T i,t represent the block of node i at time t, and the function sqrt Ti,t (x) representing the future node set confirmed signature of x is formalized as:

[0145]

[0146] Wherein, represents the future block set linked to the block x (explicit block, leaf block), and issue(y) represents the node that signs the block y, so that the output generated in the range [t, t+h] is

[0147] In a specific embodiment, the DAG multi-node consensus-based block generation method of the present embodiment further comprises the step of initializing security parameters:

[0148] The user public key and the distributed digital identity call the block chain smart contract interface to initialize the security parameters to generate the digital identity and the symmetric key;

[0149] The digital identity, the master key and the user public key are notarized and the symmetric key is encrypted to generate the security parameters;

[0150] The security parameters are returned to the client.

[0151] In a specific embodiment, the user submits an initialization security parameter request through the client, the client receives the request, calls the key initialization module setup to generate the master key, and then calls the key generation module to generate the key S k . The specific steps are as follows:

[0152] 1. Initialization (Setup): The setup module selects a bijective group G0, whose generator is g and the order is a prime number p. In Z p , select two random numbers α, β ∈ Z p as the exponent, and the public key is represented as a tuple:

[0153]

[0154] Among them, M k = (β, g α ) represents the master key. Where DID H ∈DID represents the DID of the digital file owner (Host).

[0155] 2. Generate key (keyGen): Supplement the input parameters, represented as keyGen(M k , S), where M k is the master key and S is the attribute set. The value generated by this function is the key S k . Namely:

[0156]

[0157] Among them, r ∈ Z p is a random number, and for each attribute j ∈ S, r j ∈Z p is a random number.

[0158] Input user public key PK, distributed digital identity DID H, the blockchain node calls the blockchain smart contract interface to initialize the security parameter. Then the transaction processing module of the blockchain node receives and checks the initialization security parameter request, checks through, executes the key processing smart contract, generates the digital identity DID and the symmetric key sk b , formally:

[0159] sk b = GenSymKey (Did H , P (1 k ))

[0160] Wherein, GenSymKey is a symmetric key generation function, Did represents a user distributed digital identity, P (1 k ) represents a security parameter.

[0161] The digital identity DID, the master key M k , and the user public key PK are notarized, and the symmetric key is encrypted by the following encryption function to generate the ciphertext b of the symmetric key pk and return the user:

[0162]

[0163] The security parameter is returned to the client.

[0164] Figure 7 An interaction diagram of a block generation method based on DAG multi-node consensus provided by another embodiment of the application is shown in Fig. Figure 7 , and the method comprises:

[0165] Step S701: the user submits an initialization security parameter and a file upload request;

[0166] Step S702: after the client receives the request, the key initialization setting function setup is called to generate the public key PK and the master key MK, the keyGen function is called to generate the user private key, and the master key is uploaded to the service gateway.

[0167] Step S703: the blockchain smart contract algorithm is called to initialize the security parameter.

[0168] Step S704: the transaction processing module receives the initialization security parameter and the file notarization request.

[0169] Step S705: the notarization processing smart contract is executed to notarize the user public key and the master key.

[0170] Step S706: the node executes the multi-node consensus algorithm to generate a new block.

[0171] Step S707: The consensus node initiates a vote to determine whether the block is confirmed according to the node weight. If at least one of the transactions trans(u), trans(v) fails to be verified, w(u) is not updated and a new block is not created.

[0172] Step S708: Perform block supporter algorithm to update block information.

[0173] Step S709A: Store the digital identity DID, master key M k , and user public key PK, and perform the following encryption function to encrypt the symmetric key to generate the ciphertext of the symmetric key pk b and return it to the user.

[0174]

[0175] The ciphertext file is stored in the node, and the file content CID is generated. The content address Cid is checked by Merkle verification to ensure that the root node Cid is equal to the calculated digest hash. To integrate off-chain and on-chain, Cid is integrated into x as part of ref. Let FileLink M represent the data format of the file M link, which is formally:

[0176] FileLink M = (Cid, Size, FileObj{Links, data M}, chksum)

[0177] where Size represents the size of the file M, FileObj represents the file object structure, Links represents the link array of file fragments, data M represents the data content of M, and Cid represents the content address information, which is formally:

[0178] Cid = h(M, Did1,..., Did n )

[0179] where h is a Hash function, and Did1, Did2,...., Did n represent the digital identity group that owns the file M.

[0180] Step S709B: Generate a user symmetric key and store the symmetric private key in local custody. The user public key symmetric key is encrypted and returned to the user.

[0181] Step S710: Return the security parameters to the client.

[0182] Step S711: Store the symmetric private key in local custody. ​

[0183] Step S712: return an initialization security parameter success message.

[0184] The application provides a DAG-based multi-node consensus computing system and method, which is used for solving the consistency and expansibility of multi-node consensus, and is based on a directed acyclic graph. A tree graph structure for multi-node consensus computing is constructed. A block is composed of transaction information, and an edge is composed of a transaction. A set of DAG-based on-chain and off-chain data real evaluation method is established. The method takes the transaction weight as the evaluation standard. The more consensus nodes that agree with the transaction, the greater the transaction credibility. Meanwhile, content verification is realized in the increased nodes to realize effective evaluation of transaction authenticity. The method is suitable for multi-node consensus computing in a decentralized environment, effectively solves the low efficiency, poor expansibility, high transaction cost and other shortcomings of multi-node consensus, and has good popularization value. Specifically, a DAG-based multi-node consensus computing system framework is provided. The framework provides a DAG-based framework, which can effectively replace the existing single chain structure, improves the expansibility of the chain structure, and effectively reduces the storage capacity of the chain structure. A DAG-based multi-node consensus algorithm is provided. The block weight is used to confirm the block instead of using the competitive way to confirm the leader, thereby reducing the time delay and performance bottleneck of selecting the leader.

[0185] Based on the same inventive concept, the application also provides a block generation device based on DAG multi-node consensus, which can be used to implement the method described in the above embodiments, as described in the following embodiments. Since the block generation device based on DAG multi-node consensus solves the problem in the same way as the block generation method based on DAG multi-node consensus, the embodiments of the block generation device based on DAG multi-node consensus can refer to the implementation of the block generation method based on DAG multi-node consensus, and the repeated parts will not be described again. The term "unit" or "module" used below can be a combination of software and / or hardware that implements a predetermined function. Although the system described in the following embodiments is preferably implemented in software, hardware or a combination of software and hardware is also possible and is conceived.

[0186] As shown in Figure 8 , a corresponding block generation device based on DAG multi-node consensus is also provided, which comprises:

[0187] The receiving module 801 is configured to receive a transaction request submitted by a user on a client;

[0188] The generated block determination module 802 is configured to determine a generated block set of the DAG network at a current time, wherein the current time is the time when the transaction request is received;

[0189] The candidate to-be-generated block determination module 803 is configured to determine a candidate to-be-generated block set in response to determining that the transaction request satisfies the Poisson distribution.

[0190] The verification module 804 is configured to select one generated block from the generated block set and select one candidate to-be-generated block from the candidate to-be-generated block set, and verify the transaction request in the generated block and the transaction request in the candidate to-be-generated block.

[0191] The block generation module 805 is configured to update the node weight of the generated block in response to determining that the verification is successful, and add the candidate to-be-generated block as a target to-be-generated block to the DAG network.

[0192] According to an embodiment of the present disclosure, the present disclosure further provides an electronic device, a readable storage medium, and a computer program product.

[0193] An electronic device includes at least one processor and a memory communicatively connected to the at least one processor, wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the DAG multi-node consensus-based block generation method of the foregoing embodiments.

[0194] A non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to enable a computer to perform the DAG multi-node consensus-based block generation method of the foregoing embodiments.

[0195] A computer program product includes a computer program / instruction, which, when executed by a processor, implements the steps of the DAG multi-node consensus-based block generation method of the foregoing embodiments.

[0196] Figure 9 A schematic block diagram of an example electronic device 900 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptops, desktops, tablets, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device can also represent various forms of mobile devices, such as personal digital assistants, cellular telephones, smartphones, wearable devices, and other similar computing devices. The components shown here, their connections and relationships, and their functions, are meant to be examples only, and are not meant to limit implementations of the present disclosure described and / or claimed in this document.

[0197] As Figure 9As shown, the device 900 includes a computing unit 901 that can perform various appropriate actions and processes in accordance with a computer program stored in a read-only memory (ROM) 902 or a computer program loaded into a random access memory (RAM) 903 from a storage unit 908. In the RAM 903, various programs and data required for the operation of the device 900 can also be stored. The computing unit 901, the ROM 902, and the RAM 903 are connected to each other through a bus 904. An input / output (I / O) interface 905 is also connected to the bus 904.

[0198] A plurality of components in the device 900 are connected to the I / O interface 905, including: an input unit 906, such as a keyboard, a mouse, and the like; an output unit 907, such as various types of displays, speakers, and the like; a storage unit 908, such as a magnetic disk, an optical disk, and the like; and a communication unit 909, such as a network card, a modem, a wireless communication transceiver, and the like. The communication unit 909 allows the device 900 to exchange information / data with other devices through a computer network, such as the Internet, and / or various telecommunication networks.

[0199] The computing unit 901 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 901 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various specialized artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, and the like. The computing unit 901 performs various methods and processes described above, such as the DAG multi-node consensus based block generation method.

[0200] For example, in some embodiments, the DAG multi-node consensus based block generation method can be implemented as a computer software program that is tangibly embodied in a machine-readable medium, such as the storage unit 908. In some embodiments, part or all of the computer program can be loaded and / or installed onto the device 900 via the ROM 902 and / or the communication unit 909. When the computer program is loaded into the RAM 903 and executed by the computing unit 901, one or more steps of the DAG multi-node consensus based block generation method described above can be performed. Alternatively, in other embodiments, the computing unit 901 can be configured to perform the DAG multi-node consensus based block generation method by any other appropriate means, such as by means of firmware.

[0201] The various embodiments of the systems and techniques described above can be implemented in digital electronic circuitry, integrated circuitry, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a system on a chip (SOC), a load programmable logic device (CPLD), computer hardware, firmware, software, and / or combinations thereof. These various embodiments can include implementation in one or more computer programs that are executable and / or interpretable on a programmable system including at least one programmable processor, which can be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.

[0202] Program code for carrying out methods of the present disclosure can be written in any combination of one or more programming languages. The program code can be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the program code, when executed by the processor or controller, produces the functions / operations specified in the flowcharts and / or the block diagrams. The program code can be executed entirely on a machine, partially on a machine, partially on a machine as a stand-alone software package, or entirely on a remote machine or server.

[0203] In the context of the present disclosure, a machine-readable medium can be a tangible medium that contains or stores a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can include but is not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the machine-readable storage medium will include one or more lines of electrical conductors, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0204] To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form, including acoustic, speech, or tactile input.

[0205] The systems and techniques described here can be implemented in a computing system that includes a back end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front end component (e.g., a user computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back end, middleware, or front end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (LAN), a wide area network (WAN), and the Internet.

[0206] The computer system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server is generally established by computer programs running on the respective computers and having a client-server relationship to each other. The server can be a cloud server, a server of a distributed system, or a server combined with a blockchain.

[0207] It should be understood that various forms of flow shown above can be used, with steps reordered, added, or removed. For example, the steps recited in the present disclosure can be performed in parallel, in series, or in a different order, without limitation, as long as the desired results of the present disclosure are achieved.

[0208] The specific embodiments described above are not intended to limit the scope of the present disclosure. Those skilled in the art will understand that various modifications, combinations, sub-combinations and alternatives can be made to the specific embodiments without departing from the spirit and principles of the present disclosure. Any further modifications, equivalent substitutions, improvements, combinations and the like not described above are also intended to be encompassed within the scope of the present disclosure.

[0209] The various embodiments described in this specification are intended to be illustrative only and in no way limit the scope of the application. The various embodiments described in this specification are described in progressive order. Each embodiment can be used independently and free from the others. For example, any of the hardware and program embodiments described can be used in combination with one another where supported by the underlying hardware. The embodiments described herein are not mutually exclusive, but can be combined in a number of ways. The embodiments described in this specification are intended to be illustrative only and in no way limit the scope of the application. The various embodiments described in this specification are described in progressive order. Each embodiment can be used independently and free from the others. For example, any of the hardware and program embodiments described can be used in combination with one another where supported by the underlying hardware. The embodiments described herein are not mutually exclusive, but can be combined in a number of ways. Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and the present disclosure, and will not be interpreted in an overly literal or overly formal sense unless expressly so defined herein. In addition, as used herein, "a" and "an" are defined as one or more unless indicated otherwise. Finally, terms like "another" and "one or more" mean at least one, i.e. one or more than one. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and / or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed items. As used herein, the term "about" when used in connection with a numerical value throughout the present disclosure denotes a range of values that fall within ±20% of the value. As used herein, the term "consisting essentially of" to describe a combination shall mean including, but not limited to, the recited components, integers, steps, operations, elements, and / or components but excluding other non-recited components, integers, steps, operations, elements, components, and / or groups thereof. As used herein, the term "consisting of shall mean excluding any element not specified in the claim. As used herein, the term "coupled" means directly or indirectly connected, linked, or associated. As used herein, the term "processor" means any hardware system, hardware component, integrated circuit, logic element (e.g., a logic gate, a plurality of logic gates, or other logic component), or any other hardware description of suitable execution equipment that can execute software. As used herein, the term "software" includes any sequential Figure 1 one or more functions specified by a flow or multiple flows and / or blocks. Figure 1 one or more functions specified by a flow or multiple flows and / or blocks.

[0210] Those skilled in the art will appreciate that embodiments of the present specification can be devised for a method, a system, or a computer program product. Accordingly, embodiments of the present specification can be embodied in the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, embodiments of the present specification can be in the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk memory, CD-ROM, optical storage medium, etc.) embodying computer usable program code. Each of the various embodiments of the present specification is described in a progressive manner, and reference can be made to other embodiments for the same or similar parts. Each embodiment focuses on the differences from other embodiments. In particular, for system embodiments, since they are basically similar to method embodiments, the description is relatively simple, and reference can be made to the description of the method embodiments. In the description of the present specification, the description of the terms "one embodiment", "some embodiments", "an example", "a specific example", or "some examples" means that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the embodiments of the present specification.

[0211] In the present specification, the illustrative description of the above terms does not necessarily refer to the same embodiment or example. In addition, those skilled in the art can combine and combine the different embodiments or examples described in the present specification and the features of the different embodiments or examples without contradiction. The above is only an embodiment of the embodiments of the present specification and is not intended to limit the embodiments of the present specification. The embodiments of the present specification can have various modifications and changes for those skilled in the art. Any modification, equivalent replacement, improvement, etc. within the spirit and principles of the embodiments of the present specification shall be included in the scope of the claims of the embodiments of the present specification.

Claims

1. A block generation method based on DAG multi-node consensus, characterized in that, include: Receive transaction requests submitted by users on the client side; Determine the set of generated blocks in the DAG network at the current moment, where the current moment is the time when the transaction request is received; In response to determining that the transaction request satisfies a Poisson distribution, a set of candidate blocks to be generated is determined; Select one generated block from the set of generated blocks and one candidate block to be generated from the set of candidate blocks to be generated. Verify the transaction requests in the generated block and the transaction requests in the candidate block to be generated. In response to successful verification, the node weights of the generated blocks are updated, and the candidate blocks to be generated are added to the DAG network as target blocks to be generated.

2. The method according to claim 1, characterized in that, The step of determining a candidate block set to be generated in response to determining that the transaction request satisfies a Poisson distribution includes: In response to determining that the transaction request satisfies a Poisson distribution, the block generation rate of the DAG network within a preset time period is determined, wherein the preset time period is the average execution time required for consensus nodes to issue transaction requests; A set of candidate blocks to be generated is determined based on the block generation rate, the average execution time, and the transaction requests.

3. The method according to claim 2, characterized in that, The response to determining that the transaction request satisfies a Poisson distribution and determining the block generation rate of the DAG network within a preset time period includes: In response to determining that the transaction request satisfies a Poisson distribution, a probability distribution of the number of potential transactions occurring in the transaction request is determined within the average execution time. Based on the probability distribution, the block generation rate of the DAG network within the average execution time is determined.

4. The method according to claim 2, characterized in that, The step of determining the candidate block set to be generated based on the block generation rate, the average execution time, and the transaction requests includes: Determine the number of approvals for the transaction request from the candidate blocks to be generated; In response to determining that the number of approvals is 2, the number of blocks in the candidate block set to be generated satisfies: In response to determining that the number of approvals is greater than 2, the number of blocks in the candidate block set to be generated satisfies: Wherein, L0 is the number of blocks in the candidate block set when the number of approvals is 2; The number of blocks in the candidate block set when the number of accepted blocks is k; The block generation rate; The average execution time for issuing transaction requests for the consensus node.

5. The method according to claim 1, characterized in that, Updating the node weights of the generated blocks includes: Determine the initial weights of the generated blocks in the DAG network; Determine the transaction weights of all transaction requests within the target block to be generated; The node weight is updated to the sum of the initial weight and the transaction weight.

6. The method according to claim 1, characterized in that, The step of adding the candidate blocks to be generated as target blocks to the DAG network includes: Establish a partial order relationship between the generated blocks and the target blocks to be generated; Based on the partial order relationship, the target block to be generated is added to the DAG network.

7. The method according to claim 1, characterized in that, The method also includes a step of initializing security parameters: Input the user's public key and distributed digital identity to call the blockchain smart contract interface to initialize security parameters in order to generate a digital identity and symmetric key; The digital identity, master key, and user public key are stored and the symmetric key is encrypted to generate security parameters; Return the security parameters to the client.

8. A block generation device based on DAG multi-node consensus, characterized in that, include: The receiving module is configured to receive transaction requests submitted by users on the client. The generated block determination module is configured to determine the set of generated blocks in the DAG network at the current time, wherein the current time is the time when the transaction request is received; The candidate block to be generated determination module is configured to determine a set of candidate blocks to be generated in response to determining that the transaction request satisfies a Poisson distribution; The verification module is configured to select one generated block from the set of generated blocks and one candidate block to be generated from the set of candidate blocks to be generated, and to verify the transaction requests in the generated block and the transaction requests in the candidate block to be generated. The block generation module is configured to update the node weight of the generated block in response to a successful verification, and add the candidate block to be generated as the target block to be generated to the DAG network.

9. A block generation system based on DAG multi-node consensus, characterized in that, include: Client, service gateway, storage node, blockchain node; The client communicates with the service gateway, the service gateway communicates with the storage node cluster, and the storage node cluster communicates with the blockchain node cluster. The client receives the user's transaction request and initiates smart contract deployment requests, distributed storage transaction requests, and distributed storage query requests; The service gateway provides a smart contract API to implement rate limiting and circuit breaking, security detection, file storage and access, authentication and security parameter settings; The storage node receives file read / write requests from the service gateway, performs distributed file read / write, and stores transaction information on the blockchain node. The blockchain node is configured to perform the method described in any one of claims 1 to 7 to complete transaction broadcasting, transaction execution, transaction verification, consensus, storage, and block generation.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the block generation method based on DAG multi-node consensus as described in any one of claims 1 to 7.

11. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the block generation method based on DAG multi-node consensus as described in any one of claims 1 to 7.

12. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instruction is executed by the processor, it implements the steps of the block generation method based on DAG multi-node consensus as described in any one of claims 1 to 7.

Images