Log synchronization method, system, equipment and medium

Abstract

The invention discloses a log synchronization method, system and device and a medium, and relates to the technical field of block chains. The method of the main node comprises the following steps: acquiring a request message sent by a client, and performing validity verification on a signature of the client; in response to the fact that a first verification result of the client signature is valid, adding the request message to a main node account book, and broadcasting a log entry with the request message to all slave nodes, so that each slave node feeds back a part of signature to which the slave node belongs; generating an aggregated signature according to the signatures of all the parts; generating a zero-knowledge proof according to the request message; broadcasting the aggregated signature and the zero-knowledge proof to each slave node, so that each slave node performs validity verification on the log entry, the aggregated signature and the zero-knowledge proof, and feeds back a second verification result; and according to each second verification result, submitting the log entry and broadcasting a log copy message, so that each slave node copies the log entry into a slave node account book. According to the scheme, the safety of the distributed system is improved.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and in particular to a log synchronization method, system, device, and medium. Background Art

[0002] With the continuous development of internet and computer technologies, blockchain technology has emerged. Blockchain technology has gained widespread recognition as a tamper-proof, distributed ledger with chained storage. In blockchain technology, consensus algorithms are mechanisms used to achieve consensus within a distributed network, ensuring that all nodes agree on the state of data on the blockchain. Consensus algorithms are a core component of blockchain networks, addressing issues such as node failures, malicious behavior, and network latency in distributed environments.

[0003] Currently, the traditional consensus algorithm, as a strong consistency algorithm, is prone to exposing the identity of the master node. Therefore, the privacy and security issues of the master node have become one of the research focuses of technical personnel in related fields. Summary of the Invention

[0004] The present application provides a log synchronization method, system, device, and medium to improve the security of the consensus process in a distributed system.

[0005] According to a first aspect of the present application, a log synchronization method is provided, which is applied to a master node in a distributed system, comprising:

[0006] Obtain the request message with the client signature sent by the client and verify the validity of the client signature;

[0007] In response to the first verification result of the client signature being valid, the request message is appended to the master node ledger, and a log entry with the request message is broadcast to all slave nodes, so that each slave node feeds back its own partial signature;

[0008] Generate an aggregate signature based on each partial signature;

[0009] Generate zero-knowledge proof based on the request message;

[0010] Broadcasting the aggregate signature and zero-knowledge proof to each slave node, so that each slave node verifies the validity of the log entry, the aggregate signature, and the zero-knowledge proof, and feeds back a second verification result;

[0011] Based on each second verification result, the log entry is submitted and a log copy message is broadcasted, so that each slave node copies the log entry to the slave node account book.

[0012] According to a second aspect of the present application, a log synchronization method is provided, which is applied to a slave node in a distributed system, comprising:

[0013] In response to receiving the log entry with the request message broadcast by the master node, the node feeds back the partial signature belonging to the node to the master node;

[0014] Receive the aggregate signature and zero-knowledge proof broadcast by the master node, and verify the validity of the log entries, aggregate signature, and zero-knowledge proof;

[0015] Feedback the verification results to the master node.

[0016] According to a third aspect of the present application, a distributed system is provided, comprising a master node, at least one slave node and a client; wherein,

[0017] The master node is used to implement the log synchronization method provided in the embodiment of the first aspect of the present application;

[0018] Any of the slave nodes is used to implement the log synchronization method provided in the embodiment of the second aspect of the present application;

[0019] The client is used to digitally sign the message content, and combine the message content and the client signature into a request message and send it to the master node, so that the master node replies to the request message to confirm the submission of the log entry.

[0020] According to a fourth aspect of the present application, an electronic device is provided, comprising:

[0021] at least one processor; and

[0022] a memory communicatively connected to the at least one processor; wherein,

[0023] The memory stores a computer program that can be executed by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the log synchronization method provided in the embodiment of the first aspect of the present application, and / or execute the log synchronization method provided in the embodiment of the second aspect of the present application.

[0024] According to the fifth aspect of the present application, a computer-readable storage medium is provided, which stores computer instructions, and the computer instructions are used to enable a processor to implement the log synchronization method provided in the embodiment of the first aspect of the present application, and / or implement the log synchronization method provided in the embodiment of the second aspect of the present application when executed.

[0025] According to the sixth aspect of the present application, a computer program product is provided, which includes a computer program, and when the computer program is executed by a processor, it implements the log synchronization method provided in the embodiment of the first aspect of the present application, and / or implements the log synchronization method provided in the embodiment of the second aspect of the present application.

[0026] The technical solution of the embodiment of the present application first verifies the signature of the client, so that the master node can verify the request message sent by the client and judge its authenticity to ensure the security of the message content on the chain; after the verification is valid, the master node appends the request message to its own master node account book and broadcasts the log entry with the request message, and then generates an aggregate signature based on the partial signatures obtained from each slave node, and generates a zero-knowledge proof based on the request message. The generated aggregate signature and zero-knowledge proof are sent to all slave nodes, so that the slave nodes verify the validity of the log entry, aggregate signature and zero-knowledge proof, and determine whether to put all log entries on the chain based on the verification results. The advantage of this is that in the triple verification of log entry, aggregate signature and zero-knowledge proof, the verification of aggregate signature can hide the identity of the master node, thereby improving confidentiality, and the zero-knowledge proof verification can verify the authenticity of the request message without leaking the message content, thereby improving the security of the entire log synchronization process. Therefore, the triple verification method not only completes the consensus process, but also provides confidentiality attributes in the consensus, greatly improving the security of the distributed system consensus process.

[0027] It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present application, nor is it intended to limit the scope of the present application. Other features of the present application will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0029] Figure 1 This is a flow chart of a log synchronization method applied to a master node in a distributed system according to the first embodiment of the present application;

[0030] Figure 2 This is a flow chart of a log synchronization method applied to a slave node in a distributed system according to the second embodiment of the present application;

[0031] Figure 3 This is a schematic diagram of the structure of a distributed system provided according to the third embodiment of the present application;

[0032] Figure 4 It is a structural diagram of an electronic device that implements the log synchronization method of an embodiment of the present application. DETAILED DESCRIPTION

[0033] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this application.

[0034] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in a sequence other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0035] Example 1

[0036] Figure 1 A flow chart of a log synchronization method is provided for the first embodiment of the present application. This embodiment is applicable to the case of implementing log encryption verification and synchronization in the master node of a distributed system. The method can be applied to the master node of a distributed system. The method can be executed by a log synchronization device. The log synchronization device can be implemented in the form of hardware and / or software. The device can be deployed in the master node of a distributed system. The log synchronization device can be configured in an electronic device. Figure 1 As shown, the method includes:

[0037] S110: Obtain the request message with the client signature sent by the client, and verify the validity of the client signature.

[0038] Among them, the client can be any terminal device, which interacts directly with the user, and the user can apply for any available service from the server in the distributed system through the client. The request message consists of two parts: message content and client signature. The message content can be the specific content of the service application made by the user to the server in the distributed system through the client, which is generally transmitted through a character string. The client signature can be the signature result obtained by digitally signing the message content (message) on the client side. Of course, any digital algorithm in the relevant technology can be used, and the embodiment of the present application does not limit this. Validity verification can be the process in which the master node in the distributed system verifies the client signature in the request message sent by the client, with the purpose of verifying whether the client signature complies with the preset signature rules to determine whether the message content in the request message can be chained by the master node. The master node can be the leader node elected by all nodes in the distributed system, and then the other nodes in the corresponding distributed system except the master node are all slave nodes, that is, follower nodes corresponding to the leader node.

[0039] Therefore, before executing this step, all nodes must first generate their own private key shards through the preset distributed key generation protocol. i and the corresponding public key shard y i The generation of private and public keys is used for the subsequent signature validity verification. In addition, all nodes start from the follower state. Each candidate node becomes the leader, that is, the master node, after obtaining the majority of votes by sending canvassing information. After the master node is elected, it sends heartbeat messages to all follower nodes to maintain its leadership position. The client needs to digitally sign the message content first to generate the client signature σ k , such as σ k =sign(message, sk), where sign() is the preset signature algorithm and sk is the client's own private key. After the signature is completed, the client sends a message request (message, σ) with the client's signature and message content to the master node. k ).

[0040] After receiving a message request from a client, the master node first verifies the validity of the client's signature in the message request. This verification may be performed using pre-set verification rules to determine the authenticity of the message content in the message request. Of course, these verification rules can be pre-set by those skilled in the relevant art based on actual circumstances, and are not limited in this embodiment of the present application.

[0041] S120. In response to the first verification result of the client signature being valid, append the request message to the master node account book, and broadcast the log entry with the request message to all slave nodes, so that each slave node feeds back its own partial signature.

[0042] The node's ledger can be the storage location where nodes upload messages to the blockchain. Once recorded in the ledger, content cannot be altered, so verifying its accuracy and authenticity is essential. The first verification result is the validity verification of the client signature in the previous step.

[0043] In the preceding steps, the client signature sent by the client is verified. Once the verification is successful, the authenticity of the corresponding message content is verified. This means that the master node can upload the request message to the chain, adding it to the master node's ledger. Next, log synchronization is required, broadcasting the appended request message to notify all slave nodes to also append the request message to their respective slave node ledgers. A log entry can be information updated in the master node's own ledger. To append the request message to all slave node ledgers, broadcast the log entry so that all slave nodes receive it.

[0044] The partial signature can be the signature information generated by all slave nodes themselves, that is, each slave node corresponds to a partial signature, and the partial signature is used to generate an aggregate signature for the master node.

[0045] That is to say, after the master node broadcasts the log entry to all slave nodes, it needs to obtain partial signatures from each slave node to prepare for other subsequent verification steps.

[0046] S130: Generate an aggregate signature based on the partial signatures.

[0047] Different slave nodes have different partial signatures. The master node obtains these partial signatures from each slave node and obtains an aggregate signature through a pre-set aggregation algorithm. Of course, the aggregation algorithm can adopt any one of the relevant technologies, and the embodiment of the present application does not limit this. For example, all the obtained partial signatures can be directly added together into an aggregate signature using the Jiahe splicing method. It should be noted that the aggregate signature generated in the embodiment of the present application is only related to the shared public key of the distributed system and does not contain the public key information of the master node. Therefore, it can effectively hide the identity of the master node.

[0048] S140: Generate a zero-knowledge proof according to the request message.

[0049] Zero-knowledge proof technology is a cryptographic tool that allows two parties, who have not yet established a trust relationship, to prove the validity of a proposition corresponding to confidential information without leaking any confidential information. In effect, the prover can convince the verifier that a statement is correct and valid without providing any useful information to the verifier. Zero-knowledge proof π precisely conveys this information for verification.

[0050] The request message is content that needs to be fully uploaded to the chain, but the slave nodes need to be convinced of the authenticity of the request message. Based on the request message, especially the message content in the request message, a corresponding zero-knowledge proof π is generated. This π needs to be sent to all slave nodes for verification. In this way, the authenticity and integrity of the request message can be confirmed in a completely confidential manner, ensuring that the message content has not been tampered with. Of course, the method for generating the zero-knowledge proof π can adopt any method in the relevant technology, and the embodiments of this application are not limited here.

[0051] S150. Broadcast the aggregate signature and the zero-knowledge proof to each slave node, so that each slave node verifies the validity of the log entry, the aggregate signature, and the zero-knowledge proof, and feeds back a second verification result.

[0052] The aggregate signature and zero-knowledge proof generated in the previous steps are broadcast to all slave nodes at the same time. The slave nodes have obtained three pieces of data: log entries, aggregate signatures, and zero-knowledge proofs. The slave nodes need to further verify the validity of these three pieces of data, obtain the second verification results corresponding to the verification of these three pieces of data, and feed the second verification results back to the master node.

[0053] S160. According to each second verification result, the log entry is submitted and a log copy message is broadcasted, so that each slave node copies the log entry to the slave node ledger.

[0054] The master node determines whether the verification is valid based on the feedback from the slave node. If the second verification result is valid, then the log entry can be replicated across the entire network. That is, all slave nodes will also upload the log entry to the chain and record it in their respective ledgers.

[0055] Of course, after the above steps, all nodes will execute the log entry after the log entry is marked as committed (completed on-chain), achieving consistent state machine replication.

[0056] The technical solution of the embodiment of the present application first verifies the signature of the client, so that the master node can verify the request message sent by the client and judge its authenticity to ensure the security of the message content on the chain; after the verification is valid, the master node appends the request message to its own master node account book and broadcasts the log entry with the request message, and then generates an aggregate signature based on the partial signatures obtained from each slave node, and generates a zero-knowledge proof based on the request message. The generated aggregate signature and zero-knowledge proof are sent to all slave nodes, so that the slave nodes verify the validity of the log entry, aggregate signature and zero-knowledge proof, and determine whether to put all log entries on the chain based on the verification results. The advantage of this is that in the triple verification of log entry, aggregate signature and zero-knowledge proof, the verification of aggregate signature can hide the identity of the master node, thereby improving confidentiality, and the zero-knowledge proof verification can verify the authenticity of the request message without leaking the message content, thereby improving the security of the entire log synchronization process. Therefore, the triple verification method not only completes the consensus process, but also provides confidentiality attributes in the consensus, greatly improving the security of the distributed system consensus process.

[0057] In an optional implementation, verifying the validity of the client signature in S110 may include:

[0058] S111. Determine the response value and challenge value of the client signature based on the client signature.

[0059] Among them, in the digital signature algorithm, the challenge value e can be a scalar value generated by a hash function by the commitment value r and the message content message, and the commitment value can be a random public point generated and broadcast by each participant (each node in the embodiment of the present application) during the signing process. The response value f can be a scalar value calculated by each participant based on its own private key fragmentation, temporary private key and challenge value. Of course, the response value, challenge value and commitment value are the core components of building a distributed threshold signature in the digital signature algorithm.

[0060] In fact, the response value and challenge value can be extracted from the client signature according to the preset signature algorithm rules.

[0061] S112. Calculate the commitment value of the client signature based on the response value and the challenge value.

[0062] Based on the response value and the challenge value, the commitment value r of the client signature is calculated according to the preset method:

[0063] r=g f ×y -e modp;

[0064] Among them, g is the preset generator, f is the response value, y is the client public key, e is the challenge value, and p is the pre-set security parameter. The larger the security parameter, the higher the confidentiality.

[0065] S113. Perform a hash operation on the commitment value and the message content in the request message to obtain a hash challenge value.

[0066] The hash challenge value is used to verify the validity of the client signature. A hash calculation is performed based on the commitment value and the message content to obtain the hash challenge value e′:

[0067] e′=H(message||r);

[0068] Among them, H() is the hash calculation.

[0069] S114. If the hash challenge value and the challenge value are the same, the first verification result is determined to be valid.

[0070] The hash challenge value is calculated by the aforementioned steps, and the challenge value is directly extracted by parsing the client signature. If the calculated hash challenge value and the challenge value itself are the same, the validity verification result is confirmed, that is, the first verification result is valid.

[0071] In the above implementation, the hash challenge value is calculated first, and then the validity of the client is judged by comparing whether the hash challenge value and the challenge value are the same. This not only helps the master node to perform security verification on the application message sent by the client, but also provides the basic conditions for the subsequent verification of the content sent by the master node by the slave node, which helps to improve the security of distributed system interaction and consensus.

[0072] In an optional implementation, generating the aggregate signature according to the partial signatures in S130 may include: in response to the number of received partial signatures reaching a preset threshold, aggregating the partial signatures to obtain the aggregate signature.

[0073] The preset threshold can be the minimum number of partial signatures required to generate an aggregate signature in a preset digital signature algorithm. That is, a minimum of the preset threshold number of partial signatures is required to aggregate and produce an aggregate signature. It is understood that if an aggregate signature can be generated from any number of partial signatures, its security is poor. Therefore, in this embodiment, a minimum number of required partial signatures is set to ensure the complexity of the aggregate signature, thereby improving the security of verification during the subsequent distributed system consensus process.

[0074] In an optional implementation, generating the zero-knowledge proof according to the request message in S140 may include:

[0075] S141. Perform a hash operation on the message content in the request message to obtain a message hash value.

[0076] The message hash value is the basis for generating zero-knowledge proofs. It is obtained by performing a hash operation on the message content. Continuing with the previous example:

[0077] h=H(message);

[0078] Where h is the message hash value.

[0079] S142. Generate a zero-knowledge proof according to the preset zero-knowledge proof format, signature algorithm parameters, signature algorithm rules, and message hash value.

[0080] Among them, the zero-knowledge proof format, signature algorithm parameters, and signature algorithm rules are all pre-set and can be pre-set by technical personnel in related fields according to actual conditions. The embodiments of this application do not limit this.

[0081] Based on the zero-knowledge proof format, signature algorithm parameters, signature algorithm rules and the message hash value calculated in the previous steps, a zero-knowledge proof π is generated.

[0082] In the above implementation, zero-knowledge proof is generated by pre-set formats, parameters, rules and message hash values ​​obtained by hash calculation, which provides an effective way to generate zero-knowledge proof. The existence of zero-knowledge proof can effectively protect the transmission of message content, prevent tampering, and help improve the security of the distributed system consensus process.

[0083] In an optional embodiment, submitting the log entry according to each second verification result in S160 may include: in response to the second verification result being that the number of verified valid nodes exceeds half of the number of all slave nodes, controlling the submission of the log entry.

[0084] It can be understood that in a distributed system there is a master node and multiple slave nodes. After the master node broadcasts a log entry to all slave nodes, each slave node will verify the validity of the log entry. After the verification is passed, a verification pass message will be fed back to the master node. When the number of slave nodes that have verified the validity of the master node exceeds half of the total number of slave nodes, it can be determined that the majority of slave nodes have recognized the log entry and the log entry is eligible to be submitted to the chain, so the control controls the submission of the log entry to the chain.

[0085] In the above implementation, only after the majority of slave nodes have verified that the log entry is valid can it be confirmed that the log entry can be submitted to the chain, which provides a practical and effective judgment basis for submitting the log entry to the chain, and can improve a certain degree of security while ensuring the stability of the consensus process of the distributed system.

[0086] Example 2

[0087] Figure 2 A flow chart of a log synchronization method is provided for the first embodiment of the present application. This embodiment is applicable to implementing log encryption verification and synchronization in a slave node of a distributed system. The method can be applied to any slave node in a distributed system. The method can be executed by a log synchronization device. The log synchronization device can be implemented in the form of hardware and / or software. The device can be deployed in any slave node of a distributed system. The log synchronization device can be configured in an electronic device. Figure 2 As shown, the method includes:

[0088] S210 . In response to receiving the log entry with the request message broadcast by the master node, the master node feeds back its own partial signature to the master node.

[0089] Among them, the partial signature can be the signature information generated by all slave nodes themselves, that is, each slave node corresponds to a partial signature, and the partial signature is used to generate an aggregate signature for the master node.

[0090] That is to say, after the master node broadcasts the log entry to all slave nodes, it needs to obtain partial signatures from each slave node to prepare for other subsequent verification steps.

[0091] S220. Receive the aggregate signature and zero-knowledge proof broadcast by the master node, and verify the validity of the log entry, aggregate signature, and zero-knowledge proof.

[0092] After generating the aggregate signature and zero-knowledge proof, the master node will broadcast them to all slave nodes. After any slave node receives the aggregate signature and zero-knowledge proof, it will verify the validity of the log entry, aggregate signature and zero-knowledge proof. For example, it can be verified according to pre-set validity verification rules. This embodiment of the present application does not limit this.

[0093] S230: Feedback the verification result to the master node.

[0094] Any slave node needs to feed back the verification result to the master node.

[0095] In the technical solution of the embodiment of the present application, through the triple verification method of log entries, aggregate signatures and zero-knowledge proof, not only the consensus process of the distributed system is completed, but also confidentiality attributes are provided in the consensus, which greatly improves the security of the consensus process of the distributed system.

[0096] In an optional implementation, verifying the validity of the log entry, the aggregate signature, and the zero-knowledge proof in S220 may include:

[0097] S221. Determine whether the client signature in the log entry is valid, and obtain a first determination result.

[0098] The first judgment result may be a judgment result on the validity of the client signature. It should be noted that the judgment on whether the client signature is valid is the same as the method for validating the client signature in the aforementioned embodiment, except that the executor of the judgment process is replaced by a slave node in this embodiment from the master node. Therefore, this embodiment of the present application will not be described in detail here.

[0099] S222: Determine whether the aggregate signature is valid according to a preset digital signature rule, and obtain a second determination result.

[0100] The second judgment result may be a judgment result on the validity of the aggregated signature. The preset digital signature rules may be pre-set by relevant technical personnel according to actual conditions, continuing the previous example, for example:

[0101] σ J =sum(σ i ); and, sum(σ i )=h×sum(s i )modq;

[0102] Among them, σ J is the aggregate signature generated by the master node, σ i is the partial signature of each slave node, h is the message hash value obtained by hashing the message content above, s i is the private key of each slave node, and q is another security parameter different from p in the aforementioned embodiment, which is pre-set by relevant personnel.

[0103] It is understandable that the aggregate signature can only be confirmed to be valid when the aggregate signature satisfies the above two conditions at the same time.

[0104] S223. Determine whether the zero-knowledge proof conforms to a preset format, whether it satisfies preset digital signature rules, and whether there is a message hash value corresponding to the message content in the log entry, to obtain a third judgment result.

[0105] The third judgment result may be a judgment result on the validity of the zero-knowledge proof. The generation process of the zero-knowledge proof is described in the above embodiment. The preset format, digital signature rules and message hash value are all the basis for the generation of the zero-knowledge proof.

[0106] Therefore, when verifying the validity of a zero-knowledge proof from a node, the proof's format, signature algorithm parameters, and digital signature rules are verified to ensure compliance with the proof's requirements, and the hash value declared in the proof is consistent with the message hash value recorded in the log entry. Of course, the proof is only considered valid if all of the above verification conditions are met simultaneously.

[0107] S224: In response to the first judgment result, the second judgment result, and the third judgment result being all valid, the verification result is that the log entry verification is valid.

[0108] If and only if all three of the above judgment results are valid, the log entry can be confirmed as valid. In other words, if any of the three judgment results are invalid, the verification of the log entry will be invalid.

[0109] In the above implementation, the validity of the log entry is determined by verifying the client signature, the aggregate signature, and the zero-knowledge proof, providing a reference for the master node to submit the log entry to the chain. Furthermore, the slave node can only verify the validity of the aggregate signature and cannot infer the master node's public key or any other information about the master node. This ensures that the master node's privacy is securely protected. Furthermore, the slave node verifies the validity of the zero-knowledge proof without accessing the master node's private key information, further improving the security of the distributed system. Furthermore, because the master node's information is hidden and its specific identity is unknown, it is difficult for external attackers of the distributed system to launch targeted attacks, thereby improving the distributed system's ability to resist attacks.

[0110] Example 3

[0111] Figure 3 This is a structural diagram of a distributed system provided in Example 3 of this application. Figure 3 As shown, the system includes: a master node, at least one slave node and a client.

[0112] On the one hand, the master node is used to implement the log synchronization method described in claims 1-5; the master node may include:

[0113] The client signature verification module is used to obtain the request message with the client signature sent by the client and verify the validity of the client signature;

[0114] A ledger message appending module is configured to, in response to the first verification result of the client signature being valid, append a request message to the master node ledger and broadcast a log entry with the request message to all slave nodes, so that each slave node feeds back its own partial signature;

[0115] Aggregate signature generation module, used to generate an aggregate signature based on each partial signature;

[0116] A zero-knowledge proof generation module is used to generate a zero-knowledge proof based on a request message;

[0117] a data broadcast module, configured to broadcast the aggregate signature and the zero-knowledge proof to each slave node, so that each slave node verifies the validity of the log entry, the aggregate signature, and the zero-knowledge proof, and feeds back a second verification result;

[0118] The log synchronization replication module is used to submit the log entry and broadcast the log replication message according to each second verification result, so that each slave node copies the log entry to the slave node account book.

[0119] The technical solution of the embodiment of the present application first verifies the signature of the client, so that the master node can verify the request message sent by the client and judge its authenticity to ensure the security of the message content on the chain; after the verification is valid, the master node appends the request message to its own master node account book and broadcasts the log entry with the request message, and then generates an aggregate signature based on the partial signatures obtained from each slave node, and generates a zero-knowledge proof based on the request message. The generated aggregate signature and zero-knowledge proof are sent to all slave nodes, so that the slave nodes verify the validity of the log entry, aggregate signature and zero-knowledge proof, and determine whether to put all log entries on the chain based on the verification results. The advantage of this is that in the triple verification of log entry, aggregate signature and zero-knowledge proof, the verification of aggregate signature can hide the identity of the master node, thereby improving confidentiality, and the zero-knowledge proof verification can verify the authenticity of the request message without leaking the message content, thereby improving the security of the entire log synchronization process. Therefore, the triple verification method not only completes the consensus process, but also provides confidentiality attributes in the consensus, greatly improving the security of the distributed system consensus process.

[0120] In an optional implementation, the client signature verification module may include:

[0121] The signature extraction unit is used to determine the response value and challenge value of the client signature based on the client signature;

[0122] A commitment calculation unit, used to calculate the commitment value of the client signature based on the response value and the challenge value;

[0123] A hash challenge calculation unit, configured to perform a hash operation on the commitment value and the message content in the request message to obtain a hash challenge value;

[0124] The signature verification unit determines that the first verification result is valid if the hash challenge value and the challenge value are the same.

[0125] In an optional implementation, the aggregate signature generation module may be specifically configured to:

[0126] In response to the number of partial signatures received reaching a preset threshold, the partial signatures are aggregated to obtain an aggregate signature.

[0127] In an optional implementation, the zero-knowledge proof generation module may include:

[0128] A message hash calculation unit, configured to perform a hash operation on the message content in the request message to obtain a message hash value;

[0129] The zero-knowledge proof generation unit is used to generate a zero-knowledge proof according to a preset zero-knowledge proof format, signature algorithm parameters, signature algorithm rules and message hash value.

[0130] In an optional implementation, the log synchronization replication module may be specifically used to:

[0131] In response to the second verification result being that the number of verified valid nodes exceeds half of the number of all slave nodes, the control commits the log entry.

[0132] On the other hand, any of the slave nodes is used to implement the log synchronization method described in claims 6-7; wherein the slave node may include:

[0133] A partial signature feedback module is configured to feedback its own partial signature to the master node in response to receiving a log entry with a request message broadcast by the master node;

[0134] The validity verification module is used to receive the aggregate signature and zero-knowledge proof broadcast by the master node and verify the validity of the log entries, aggregate signature and zero-knowledge proof;

[0135] The verification result feedback module is used to feed back the verification results to the master node.

[0136] Through the triple verification of log entries, aggregate signatures and zero-knowledge proof, not only the consensus process of the distributed system is completed, but also confidentiality properties are provided in the consensus, which greatly improves the security of the consensus process of the distributed system.

[0137] In an optional implementation, the validity verification module may include:

[0138] a first judging unit, configured to judge whether the client signature in the log entry is valid, and obtain a first judging result;

[0139] A second judgment unit is used to judge whether the aggregate signature is valid according to a preset digital signature rule, and obtain a second judgment result;

[0140] a third judgment unit, configured to judge whether the zero-knowledge proof conforms to a preset format, whether it satisfies preset digital signature rules, and whether there is a message hash value corresponding to the message content in the log entry, and obtain a third judgment result;

[0141] The log verification unit is configured to verify that the log entry is valid in response to the first judgment result, the second judgment result, and the third judgment result being all valid.

[0142] On the other hand, the client is used to digitally sign the message content, and combine the message content and the client signature into a request message and send it to the master node, so that the master node replies to the request message to confirm the submission of the log entry.

[0143] The master node or slave node provided in the embodiments of the present application can execute the log synchronization method provided in the corresponding embodiments of the present application, and has the corresponding functional modules and beneficial effects for executing each corresponding log synchronization method.

[0144] Example 4

[0145] Figure 4 A schematic diagram of the structure of an electronic device 10 that can be used to implement an embodiment of the present application is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices (such as helmets, glasses, watches, etc.) and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present application described and / or required herein.

[0146] like Figure 4 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12, a random access memory (RAM) 13, etc., which is communicatively connected to the at least one processor 11. The memory stores a computer program that can be executed by the at least one processor. The processor 11 can perform various appropriate actions and processes according to the computer program stored in the read-only memory (ROM) 12 or the computer program loaded from the storage unit 18 into the random access memory (RAM) 13. Various programs and data required for the operation of the electronic device 10 can also be stored in the RAM 13. The processor 11, ROM 12, and RAM 13 are connected to each other via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0147] Multiple components in the electronic device 10 are connected to the I / O interface 15, including an input unit 16, such as a keyboard, a mouse, etc.; an output unit 17, such as various types of displays, speakers, etc.; a storage unit 18, such as a magnetic disk, an optical disk, etc.; and a communication unit 19, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 19 allows the electronic device 10 to exchange information / data with other devices via a computer network such as the Internet and / or various telecommunication networks.

[0148] The processor 11 can be any general-purpose and / or specialized processing component with processing and computing capabilities. Some examples of the processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various specialized artificial intelligence (AI) computing chips, various processors that run machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The processor 11 executes the various methods and processes described above, such as the log synchronization method.

[0149] In some embodiments, the log synchronization method can be implemented as a computer program that is tangibly contained in a computer-readable storage medium, such as the storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 10 via the ROM 12 and / or the communication unit 19. When the computer program is loaded into the RAM 13 and executed by the processor 11, one or more steps of the log synchronization method described above can be performed. Alternatively, in other embodiments, the processor 11 can be configured to perform the log synchronization method in any other appropriate manner (e.g., by means of firmware).

[0150] Various embodiments of the systems and techniques described herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), system-on-chip systems (SOCs), programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments can include being implemented in one or more computer programs that are executable and / or interpreted on a programmable system that includes at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0151] Computer programs for implementing the methods of the present application may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when the computer program is executed by the processor, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The computer program may be executed entirely on the machine, partially on the machine, as a stand-alone software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0152] In the context of the present application, a computer-readable storage medium can be a tangible medium that can contain or store a computer program for use by an instruction execution system, device or equipment or used in combination with an instruction execution system, device or equipment. A computer-readable storage medium can include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared or semiconductor systems, devices or equipment, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium can be a machine-readable signal medium. A more specific example of a machine-readable storage medium can include an electrical connection based on one or more lines, 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 disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0153] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device 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 pointing device (e.g., a mouse or trackball) through which the user can provide input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, the 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 input, voice input, or tactile input).

[0154] The systems and techniques described herein can be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such back-end components, middleware components, 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), a blockchain network, and the Internet.

[0155] A computing system may include clients and servers. The clients and servers are typically remote from each other and typically interact via a communication network. This client-server relationship arises through computer programs running on the respective computers, creating a client-server relationship. The server may be a cloud server, also known as a cloud computing server or cloud host. This server is a hosting product within the cloud computing service ecosystem that addresses the management difficulties and limited scalability of traditional physical hosting and VPS services.

[0156] The present application also discloses a computer program product, comprising a computer program that, when executed by a processor, implements the log synchronization method provided in any of the embodiments of the present application. This program product and the log synchronization method disclosed in each embodiment of the present application share the same inventive concept and are therefore not described in detail here.

[0157] It should be understood that the various forms of the processes shown above can be used to reorder, add, or delete steps. For example, the steps described in this application can be performed in parallel, sequentially, or in a different order, as long as the desired results of the technical solution of this application can be achieved. This is not limited herein.

[0158] The above specific embodiments do not constitute a limitation on the scope of protection of this application. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions may be made based on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application shall be included within the scope of protection of this application.

Claims

1. A log synchronization method, characterized in that: Master nodes used in distributed systems include: Obtaining a request message with a client signature sent by the client and verifying the validity of the client signature; In response to the first verification result of the client signature being valid, appending the request message to the master node ledger, and broadcasting a log entry with the request message to all slave nodes, so that each slave node feeds back its own partial signature; generating an aggregate signature based on the partial signatures; Generate a zero-knowledge proof according to the request message; broadcasting the aggregate signature and the zero-knowledge proof to each of the slave nodes, so that each of the slave nodes verifies the validity of the log entry, the aggregate signature, and the zero-knowledge proof, and feeds back a second verification result; According to each second verification result, the log entry is submitted and a log copy message is broadcasted, so that each slave node copies the log entry to a slave node account book.

2. The method according to claim 1, characterized in that The verification of the validity of the client signature includes: Determining a response value and a challenge value of the client signature according to the client signature; Calculating a commitment value of the client signature based on the response value and the challenge value; Performing a hash operation on the commitment value and the message content in the request message to obtain a hash challenge value; If the hash challenge value and the challenge value are the same, the first verification result is determined to be valid.

3. The method according to claim 1, characterized in that Generating an aggregate signature according to each of the partial signatures includes: In response to the number of received partial signatures reaching a preset threshold, the partial signatures are aggregated to obtain the aggregate signature.

4. The method according to claim 1, wherein Generating a zero-knowledge proof according to the request message includes: Performing a hash operation on the message content in the request message to obtain a message hash value; The zero-knowledge proof is generated according to the preset zero-knowledge proof format, signature algorithm parameters, signature algorithm rules and the message hash value.

5. The method according to claim 1, wherein Submitting the log entry according to each second verification result includes: In response to the second verification result being that the number of verified valid nodes exceeds half of the number of all slave nodes, control is performed to commit the log entry.

6. A log synchronization method, characterized in that: Slave nodes used in distributed systems include: In response to receiving a log entry with a request message broadcast by the master node, feeding back the partial signature belonging to the master node; Receive the aggregate signature and zero-knowledge proof broadcast by the master node, and verify the validity of the log entry, the aggregate signature, and the zero-knowledge proof; The verification result is fed back to the master node.

7. The method according to claim 6, characterized in that The validating the log entry, the aggregate signature, and the zero-knowledge proof includes: Determine whether the client signature in the log entry is valid, and obtain a first determination result; Determine whether the aggregate signature is valid according to a preset digital signature rule, and obtain a second determination result; Determine whether the zero-knowledge proof conforms to a preset format, satisfies preset digital signature rules, and whether there is a message hash value corresponding to the message content in the log entry, to obtain a third judgment result; In response to the first judgment result, the second judgment result and the third judgment result being all valid, the verification result is that the log entry is verified to be valid.

8. A distributed system, characterized in that: It includes a master node, at least one slave node and a client; wherein, The master node is used to implement the log synchronization method described in claims 1-5; Any of the slave nodes is used to implement the log synchronization method described in claims 6-7; The client is used to digitally sign the message content, and combine the message content and the client signature into a request message and send it to the master node, so that the master node replies to the request message to confirm the submission of the log entry.

9. An electronic device, characterized in that: The electronic device comprises: at least one processor; and a memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the log synchronization method described in any one of claims 1-5, and / or execute the log synchronization method described in any one of claims 6-7.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the log synchronization method according to any one of claims 1 to 5 and / or the log synchronization method according to any one of claims 6 to 7 when executed.

Images