Certificate generation method and device and storage medium

Abstract

The invention discloses a proof generation method and device and a storage medium. The method comprises the steps of obtaining a plurality of transactions stored in a block; the initial states of the plurality of transactions have a dependency relationship; updating the initial state of each transaction before pre-execution based on the first state generated when each transaction is pre-executed and the dependency relationship among the plurality of transactions, so as to obtain the updated second state of each transaction; wherein the second states of the transactions do not have a dependency relationship; executing a plurality of transactions in parallel based on the updated second states of the transactions, and recording execution tracks of the transactions during parallel execution; and generating a proof based on the execution track corresponding to each transaction. Through the method, the generation efficiency of the proof can be improved, and the verification efficiency of the transaction is further improved.

Description

Technical Field

[0001] This application relates to the field of Internet technologies, and particularly to a proof generation method, device, and storage medium. Background Art

[0002] In a blockchain network, the verification process of transactions is a key link. This involves the collaborative work of block generation nodes and block verification nodes. The block generation nodes are responsible for generating blocks containing multiple transactions and sending them to the block verification nodes for verification to confirm whether the transactions are legal or correct, which usually relies on zero-knowledge proofs for verifying the legality or correctness of transactions.

[0003] The generation of zero-knowledge proofs depends on the execution traces recorded during the transaction execution process. Currently, due to the dependency relationships between multiple transactions, most blockchain systems adopt a serial execution method to generate the execution traces of transaction execution. This means that each transaction is executed one by one in sequence to generate the corresponding execution traces, and then the zero-knowledge proofs are generated using the execution traces. The proof generation efficiency is severely limited. Especially in scenarios with a large number of transactions, the serial execution method will lead to a significant decrease in the proof generation efficiency, thereby affecting the verification efficiency of transactions. Summary of the Invention

[0004] The main technical problem to be solved by this application is to provide a proof generation method, device, and storage medium, which can improve the proof generation efficiency and thus improve the transaction verification efficiency.

[0005] To solve the above technical problem, a technical solution adopted by this application is: providing a proof generation method, which includes: obtaining a plurality of transactions stored in a block; there are dependency relationships between the initial states of the plurality of transactions; based on the first state generated by each transaction during pre-execution and the dependency relationships between the plurality of transactions, updating the initial state of each transaction before pre-execution to obtain the updated second state of each transaction; wherein, there are no dependency relationships between the second states of each transaction; based on the updated second states of each transaction, executing the plurality of transactions in parallel and recording the execution traces of each transaction during parallel execution; generating a proof based on the execution traces corresponding to each transaction.

[0006] Among them, based on the first state generated by each transaction during pre-execution and the dependency relationships between the plurality of transactions, updating the initial state of each transaction before pre-execution to obtain the updated second state of each transaction includes: sequentially executing each transaction according to the pre-execution order of the plurality of transactions to obtain the first state of each transaction; wherein, the pre-execution order is determined using the dependency relationships between the initial states of the plurality of transactions; taking the initial state of the first transaction as the second state of the first transaction, and using the first state of the previous transaction that has a dependency relationship with the non-first transaction to update and obtain the second state of the non-first transaction.

[0007] Among them, the step of sequentially executing each transaction according to the pre-execution order of multiple transactions to obtain the first state of each transaction is executed by a first virtual machine, and the first virtual machine includes a translated virtual machine; and / or, the step of parallelly executing multiple transactions based on the updated second state of each transaction and recording the execution traces of each transaction during parallel execution is executed by a second virtual machine, and the second virtual machine is an interpreted virtual machine.

[0008] Among them, the step of parallelly executing multiple transactions based on the updated second state of each transaction and recording the execution traces of each transaction during parallel execution is executed by at least two second virtual machines; before parallelly executing multiple transactions based on the updated second state of each transaction and recording the execution traces of each transaction during parallel execution, the method further includes: finding out the associated instructions of each transaction from several instructions in the target execution object; the target execution object is used to execute multiple transactions in a block, and the several instructions are obtained by parsing the target execution object; allocating the multiple transactions and the corresponding associated instructions to at least two second virtual machines; among them, each second virtual machine is allocated at least one transaction.

[0009] Among them, parallelly executing multiple transactions based on the updated second state of each transaction and recording the execution traces of each transaction during parallel execution includes: using each second virtual machine to parallelly execute the corresponding transaction based on the associated instructions of the allocated transaction and the corresponding second state, and recording the execution traces of each transaction during parallel execution; among them, the execution trace includes the values of the registers of the corresponding second virtual machine and the state information of the memory recorded during the execution of the corresponding transaction by the associated instruction; the proof is used to prove whether the execution process of the associated instruction of each transaction for the corresponding transaction is correct.

[0010] Among them, allocating the multiple transactions and the corresponding associated instructions to at least two second virtual machines includes: allocating transactions and the associated instructions corresponding to the transactions to each second virtual machine based on the current load condition data of each second virtual machine; among them, the load condition data is negatively correlated with the number of allocated transactions.

[0011] Among them, the step of finding out the associated instructions of each transaction from several instructions in the target execution object and allocating the multiple transactions and the corresponding associated instructions to at least two first virtual machines is executed by a third virtual machine; the second virtual machine and the third virtual machine are of the same type, and the third virtual machine is or is not one of at least two second virtual machines.

[0012] Among them, generating a proof based on the execution traces corresponding to each transaction includes: merging the execution traces corresponding to each transaction to obtain a target execution trace; using the target execution trace to generate a proof.

[0013] To solve the above technical problems, another technical solution adopted by this application is: to provide an electronic device, including a memory and a processor coupled to each other, where the memory stores program instructions; the processor is configured to execute the program instructions stored in the memory to implement the above method.

[0014] To solve the above technical problems, another technical solution adopted by this application is: to provide a computer-readable storage medium for storing program instructions that can be executed to implement the above method.

[0015] In the above solution, first, by using the first state generated during pre-execution of each transaction and the dependency relationship between the initial states among multiple transactions to update the initial state of each transaction before pre-execution, and obtaining the corresponding updated second state, there is no dependency relationship between the second states of each transaction. Then, based on the updated second states of each transaction, multiple transactions are executed in parallel (at this time, there is no dependency relationship between transaction executions), and the execution traces of each transaction during parallel execution are recorded. Furthermore, corresponding proofs are generated based on the execution traces corresponding to each transaction. Compared with the method of generating the execution traces of transaction executions by using serial execution, the above solution of this application can significantly improve the efficiency of obtaining the execution traces of each transaction by pre-solving the dependencies between transactions so that the transactions can be executed in parallel and simultaneously recording the execution traces corresponding to each transaction. As a result, the efficiency of proof generation and the overall transaction verification efficiency can be improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 is a schematic flowchart of an embodiment of the proof generation method provided by this application; Figure 2 is Figure 1 a schematic flowchart of an embodiment of step S12 shown; Figure 3 is a schematic framework diagram of an embodiment of the electronic device provided by this application; Figure 4 is a schematic framework diagram of the computer-readable storage medium provided by this application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0017] To make the objectives, technical solutions, and effects of this application clearer and more definite, the following further describes this application in detail with reference to the accompanying drawings and by way of examples.

[0018] In addition, if descriptions such as "first", "second", etc. are involved in the embodiments of this application, the descriptions of "first", "second", etc. are only for descriptive purposes and should not be construed as indicating or implying their relative importance or implicitly specifying the quantity of the indicated technical features. Thus, the features defined with "first", "second" may explicitly or implicitly include at least one such feature. In addition, the technical solutions between various embodiments may be combined with each other, but it must be based on the ability of those of ordinary skill in the art to implement. When the combination of technical solutions results in contradictions or cannot be implemented, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection required by this application.

[0019] Please refer to Figure 1 , Figure 1 which is a schematic flowchart of an embodiment of the proof generation method provided by this application. It should be noted that if there are substantially the same results, this embodiment is not limited to Figure 1 the process sequence shown. As Figure 1 shown, this embodiment includes: S11: Obtain multiple transactions stored in the block; there is a dependency relationship between the initial states of the multiple transactions.

[0020] In a blockchain network, a transaction is the basic unit of data exchange, which contains transfer instructions of value, information, or assets from one party to another. Transaction data is broadcast through the blockchain network and confirmed and verified throughout the network through a consensus mechanism to ensure the legality and immutability of the transaction.

[0021] A transaction usually contains information such as the two parties to the transaction (sender and receiver), the transaction amount, and the timestamp. In some cases, a transaction may also contain the terms or conditions of a smart contract to implement more complex economic logic. After a transaction is broadcast in the blockchain network, it needs to be verified by a certain number of nodes before it can be confirmed. The confirmed transaction will be recorded on the blockchain to form an immutable historical record.

[0022] However, due to the dependency relationship between the initial states of transactions, the generation of proofs and the verification efficiency of transactions are low. The dependency relationship between the initial states of transactions can be understood as that in the process of transactions, the execution or result of one transaction depends on the execution or result of another or multiple other transactions.

[0023] In this embodiment, the existence of a dependency relationship between the initial states of multiple transactions means that there is a dependency relationship between the initial states of at least two of the multiple transactions. That is, among the multiple transactions, there may be a dependency relationship between the initial states of some transactions, while there is no dependency relationship between the initial states of other transactions.

[0024] S12: Update the initial state of each transaction before pre-execution based on the first state generated during the pre-execution of each transaction and the dependency relationships among multiple transactions, so as to obtain the updated second state of each transaction; wherein, there are no dependency relationships among the second states of each transaction.

[0025] There are no dependency relationships among the second states of each transaction updated in step S12 before pre-execution. The pre-execution in this embodiment is not a real transaction execution, but a simulated transaction execution. Through the simulated transaction execution, the first state after the corresponding transaction execution generated during the simulated execution of each transaction and the second state of the transaction before the simulated execution are obtained.

[0026] In some embodiments, please refer to Figure 2 , Figure 2 is Figure 1 a schematic flowchart of an embodiment of step S12 shown in. In this embodiment, step S12 further includes: S21: Execute each transaction in sequence according to the pre-execution order of multiple transactions to obtain the first state of each transaction; wherein, the pre-execution order is determined by using the dependency relationships among the initial states of multiple transactions.

[0027] S22: Use the initial state of the first transaction as the second state of the first transaction, and update the second state of the non-first transaction by using the first state of the previous transaction that has a dependency relationship with the non-first transaction.

[0028] It should be noted that among the multiple transactions in a block, there are at least two transactions whose initial states have dependency relationships (the execution result of one transaction affects the state of another transaction before execution). In a smart contract or a decentralized application, transactions generally involve state updates. If multiple transactions with dependency relationships are not executed in the correct order, the subsequent application states may become inconsistent or invalid, resulting in transaction verification failure.

[0029] In this embodiment, the pre-execution order is determined by using the dependency relationships among the initial states of multiple transactions. In some implementation scenarios, before packing transactions into a block, the verification node may sort the transactions to ensure that transactions with dependency relationships are processed in the correct order, that is, the order of the transactions recorded in the block can be used as the pre-execution order of multiple transactions.

[0030] In this embodiment, first execute each transaction in sequence according to the pre-execution order of multiple transactions to obtain the first state of each transaction. Then, for the transaction at the first position in the pre-execution order, there is no other transaction that affects its initial state. Therefore, the initial state of this first transaction before pre-execution will not be affected by other transactions. Therefore, the second state of this first transaction is the initial state of this transaction itself, that is, when pre-executing this first transaction, the initial state of this first transaction is the initial state of this transaction itself.

[0031] For transactions that are not in the first position in the pre-execution order, there may be other transactions that affect their initial state (the second state) before pre-execution. Therefore, for non-first-position transactions, if there is a previous transaction with a dependency relationship, the first state generated during pre-execution of the previous transaction can be used to update the second state of the non-first-position transaction before pre-execution. It can be understood that the second state of the non-first-position transaction is the transaction state after considering the impact of the transaction with a dependency relationship on the initial state and using this impact to update the initial state. That is, the "second state" of the non-first-position transaction is an adjusted state, and this adjustment is based on the impact of the previous transaction with a dependency relationship on the initial state. In other words, this state not only considers the initial state of the non-first-position transaction itself but also incorporates all possible impacts that the dependent previous transaction may have on it. In addition, when pre-executing the non-first-position transaction, the initial state of the non-first-position transaction should be the updated second state.

[0032] Among them, the initial states between transactions can include the initial states of the trading parties' accounts corresponding to the transactions (such as account balances, stored data, etc.). The corresponding first state includes the first states corresponding to the trading parties respectively, and the second state includes the second states corresponding to the trading parties respectively. Using the first state of the previous transaction with a dependency relationship with the non-first-position transaction to update the second state of the non-first-position transaction includes: updating the first state of the target party with a state dependency with the non-first-position transaction among the trading parties of the previous transaction with a dependency relationship with the non-first-position transaction to the second state of the target party in the non-first-position transaction. Among them, the target party is at least one of the trading parties of the previous transaction with a dependency relationship with the non-first-position transaction, and is specifically determined according to the state dependency relationship between the trading parties corresponding to each transaction in the two transactions. If the trading parties of transaction 1 and the trading parties of transaction 2 are the same, the target party is the trading parties of transaction 1. If only one trading party is the same between the trading parties of transaction 1 and the trading parties of transaction 2, the target party is the same trading party in transaction 1 and transaction 2.

[0033] Exemplarily, in a blockchain network, there are three users: Alice, Bob, and Charlie. They have carried out a series of transactions, and there are dependency relationships between the initial states of these transactions. However, by pre-executing these transactions and updating their states, these transactions can be made to have no dependency relationships during subsequent parallel execution.

[0034] For example, a block includes multiple transactions, namely transaction T1, transaction T2... transaction Tn. The pre-execution order is determined according to the dependency relationship among the initial states of transaction T1, transaction T2... transaction Tn. For the sake of explanation, specifically take two of these transactions, namely transaction T1 and transaction T2 as examples. Among them, the pre-execution order is to execute transaction T1 first and then transaction T2. Before executing each transaction in the block, Alice's initial account state is 20 tokens remaining, Bob's initial account state is 0 tokens remaining, and Charlie's initial account state is 5 tokens remaining.

[0035] Transaction T1 is that Alice pays 10 tokens to Bob, and transaction T2 is that Bob pays 5 tokens to Charlie. Of course, there can be subsequent transactions such as transaction T3 and even transaction T4, etc., which will not be elaborated here.

[0036] First, pre-execute transaction T1 (here it is considered that transaction T1 is the first transaction in the block): Alice pays 10 tokens to Bob. Correspondingly, before pre-executing transaction T1, there are no other transactions affecting its initial state. Therefore, the initial states and the second states of both parties (Alice and Bob) of transaction T1 are the same, both being Alice with 20 tokens remaining and Bob with 0 tokens remaining. After pre-executing transaction T1 (Alice pays 10 tokens to Bob) based on the initial state of transaction T1, the first state of transaction T1 generated includes Alice with 10 tokens remaining and Bob with 10 tokens remaining.

[0037] Then, pre-execute transaction T2: Bob pays 5 tokens to Charlie. It should be noted that after the pre-execution of transaction T1 and before the pre-execution of transaction T2, Bob's account state has changed. It is not the initial state (0 tokens remaining) at the beginning (before the pre-execution of transaction T1 and transaction T2), but 10 tokens remaining. It can be seen that Bob's account state in transaction T2 is affected by transaction T1. Therefore, there is transaction T1 that affects the initial state of transaction T2 before its pre-execution, and there is a dependency relationship between the initial states of transaction T2 and transaction T1. Therefore, before actually pre-executing transaction T2, the initial state of transaction T2 should be updated to Bob with 10 tokens remaining and Charlie with 5 tokens remaining. That is, update the first state of Bob (Bob with 10 tokens remaining) after the pre-execution of transaction T1, which has a dependency relationship with transaction T2, to the second state of Bob before the pre-execution of transaction T2. Finally, the second state of transaction T2 before the pre-execution includes Bob with 10 tokens remaining and Charlie with 5 tokens remaining.

[0038] Among them, after pre-executing transaction T2 (Bob pays 5 tokens to Charlie) in the second state after the initial state has been updated based on transaction T2 (Bob has 10 tokens remaining, Charlie has 5 tokens remaining), the first state of transaction T2 generated includes Bob having 5 tokens remaining and Charlie having 10 tokens remaining. In other embodiments, if there is also transaction T3 for transaction T2 and there is also a state dependency between transaction T2 and transaction T3, then after first updating the second state of transaction T3 using the first state of transaction T2 generated, transaction T3 can be pre-executed.

[0039] It can be understood that there is no dependency between the second state of the updated transaction T2 and the second state of transaction T1 above, that is, subsequently, even when transaction T1 has not been executed yet, executing transaction T2 based on the second state of transaction T2 will not cause a conflict (dependency) in the account states of the parties to transactions T1 and T2.

[0040] Generally speaking, the above solution makes there be no dependency between the second states of each transaction through the way of pre-execution and state update. The specific reasons are as follows: First, according to the initial state dependency relationship between transactions, determine the pre-execution order of the transactions. This order ensures that transactions with dependency relationships can be processed in the correct order.

[0041] In addition, in accordance with the determined pre-execution order, execute each transaction in turn. The first state of each transaction after pre-execution obtained reflects the result after the transaction is executed. For the first transaction (i.e., the transaction that does not depend on other transactions), since there are no other transactions affecting its initial state, its second state is its initial state; for non-first transactions, use the first state of the previous transaction that has a dependency relationship with it to update and obtain the second state of this non-first transaction. This update process takes into account the influence of the dependency relationship on the initial state of the transaction.

[0042] Through the above steps, in the updated second state (i.e., the state before pre-execution) of each transaction, all possible influences of dependency relationships on it have been incorporated. Therefore, there are no longer dependency relationships between these transactions during subsequent execution.

[0043] In one embodiment, the steps of step S21 and step S22 above are executed by the first virtual machine. The first virtual machine can be a translation-type virtual machine or an interpretation-type virtual machine.

[0044] Considering that a translation virtual machine is an execution environment that can directly convert target execution objects (such as programs) for executing multiple transactions into low-level machine code (such as x86 assembly), in order to improve the pre-execution efficiency of multiple transactions, the translation virtual machine can be used to execute step S21 and step S22. It should be noted that the translation virtual machine does not need to record the corresponding execution trace during the execution of the transaction, while the interpretive virtual machine needs to record the corresponding execution trace during the execution of the transaction. Therefore, compared with the interpretive virtual machine, using the translation virtual machine to execute multiple transactions can quickly obtain the states of each transaction after execution.

[0045] Of course, in other embodiments, relevant algorithms can also be directly used to update the initial states of each transaction before pre-execution based on the first states generated by each transaction during pre-execution and the dependency relationships between multiple transactions, so that there are no dependency relationships between the second states of each updated transaction. For the specific principle, reference can be made to Figure 2 the relevant descriptions of the embodiments shown, and details will not be elaborated here.

[0046] It should be noted that the above can also be grouped based on the dependency relationships between transactions. Transactions with state dependencies are grouped into the same group, and transactions without state dependencies are grouped into different groups. Since there are state dependencies between several transactions belonging to the same group, the transactions in this group can be executed in sequence according to the pre-execution order determined by the dependency relationship; in addition, since there are no state dependencies between transactions in different groups, the transactions in different groups can be executed in parallel.

[0047] S13: Parallelly execute multiple transactions based on the updated second states of each transaction, and record the execution traces of each transaction during parallel execution.

[0048] As can be seen from step S12, there are no dependency relationships between the second states of each transaction. Therefore, multiple transactions can be directly executed in parallel based on the updated second states of each transaction.

[0049] In one embodiment, step S13 is executed by a second virtual machine. Optionally, the second virtual machine is an interpretive virtual machine that can record the execution traces of each transaction during parallel execution.

[0050] In one implementation, to accelerate the parallel execution efficiency of multiple transactions, step S13 is executed by at least two second virtual machines.

[0051] Before executing step S13 using at least two second virtual machines, first find the associated instructions for each transaction from several instructions in the target execution object for executing multiple transactions in the block, and then allocate the multiple transactions and the associated instructions corresponding to each transaction to at least two second virtual machines, so that each second virtual machine among the multiple second virtual machines can execute the corresponding transaction based on the allocated transaction and the corresponding associated instructions, and record the execution trace of each transaction during parallel execution.

[0052] Among them, each second virtual machine is allocated at least one transaction. The specific number of second virtual machines can be determined according to the number of transactions in the block and the desired execution efficiency.

[0053] The target execution object can be, but is not limited to, a program. The several instructions are obtained by parsing the target execution object.

[0054] In one embodiment, the steps of parsing the target execution object to obtain several instructions, finding the associated instructions for each transaction from the several instructions in the target execution object, and allocating the multiple transactions and the corresponding associated instructions to at least two second virtual machines are executed by a third virtual machine. Among them, the third virtual machine is, for example, an interpreted virtual machine.

[0055] It should be noted that the second virtual machine executes the transaction by running the target execution object (which can be understood as a program) in the execution environment of the virtual machine. Before running the target execution object, it is necessary to parse each instruction from the target execution object, and then use the running of each instruction to execute each transaction. And the instructions used to execute each transaction may be different. Among them, the third virtual machine can clarify which instructions can be used to execute which transaction during the process of parsing each instruction.

[0056] At the same time, it should be noted that the third virtual machine in this embodiment can be one of the above at least two second virtual machines, or another virtual machine other than the above second virtual machines. In the case where the third virtual machine is one of the above at least two second virtual machines, when the third virtual machine allocates transactions, it can also allocate a part of the transactions to itself (the third virtual machine).

[0057] In addition, in order to improve the parallel processing efficiency of multiple transactions, when allocating transactions to each second virtual machine, the transactions and the associated instructions corresponding to the transactions can be allocated to each second virtual machine according to the current load situation data of each second virtual machine. Among them, the load situation data of each second virtual machine is negatively correlated with the number of allocated transactions. That is to say, more transactions can be allocated to the second virtual machine that executes transactions faster.

[0058] In addition, the execution trace corresponding to each transaction includes the values of the registers of the corresponding second virtual machine and the status information of the memory recorded during the execution of the associated instructions of each transaction. Specifically, the values of the registers and the status information of the memory corresponding to each transaction at different execution stages (before execution, during execution, and after execution) are recorded. Among them, the values of the registers of the second virtual machine and the status information of the memory are used to characterize the execution status of the transaction. The execution trace is used to generate a proof, and the finally generated proof is used to prove whether the execution process of the associated instructions of each transaction is correct.

[0059] S14: Generate a proof based on the execution trace corresponding to each transaction.

[0060] In one embodiment, a sub-proof can be generated respectively using the execution trace corresponding to each transaction, and then the sub-proofs corresponding to each transaction are aggregated to obtain the aggregated proof.

[0061] In another embodiment, considering that the time-consuming for aggregating each proof to obtain the aggregated proof is long, the execution traces corresponding to each transaction are first merged to generate a target execution trace, and then the merged target execution trace is used to generate a proof. Among them, the execution traces corresponding to each transaction can be merged according to the execution order of the transactions determined by the dependency relationship between the states of the transactions to obtain the target execution trace.

[0062] Among them, the generated proof is used to prove that the execution processes of multiple transactions are all correct, and is used for the verifier to verify whether the transaction execution is correct based on this proof.

[0063] In the above solution, first, the initial state before pre-execution of each transaction is updated through the first state generated by each transaction during pre-execution and the dependency relationship between multiple transactions to obtain the corresponding updated second state, so that there is no dependency relationship between the second states of each transaction. Then, multiple transactions are executed in parallel based on the updated second states of each transaction (at this time, there is no dependency relationship between transaction executions), and the execution trace of each transaction during parallel execution is recorded. Furthermore, a corresponding proof is generated based on the execution trace corresponding to each transaction. Compared with the method of generating the execution trace of transaction execution by using a serial execution method, the above solution of the present application can significantly improve the efficiency of obtaining the execution trace of each transaction by pre-solving the dependencies between transactions so that the transactions can be executed in parallel and the execution traces corresponding to each transaction can be recorded in parallel, and thus can improve the efficiency of proof generation and the efficiency of the entire transaction verification.

[0064] It should be noted that the execution subject of the above solution is an electronic device, and this electronic device can run any of the above virtual machines. For specific electronic devices, reference can be made to the relevant descriptions in the embodiments shown below. Figure 3 as described in the following embodiments.

[0065] In addition, the above virtual machine is a dedicated execution environment for generating and verifying zero-knowledge proofs (proofs generated based on the above execution traces) in the blockchain system, enabling verifiers to independently verify the correctness of the transaction execution process without accessing or viewing the specific transactions and without re-executing the transactions. That is, the generated zero-knowledge proofs enable the effective verification of the legality and correctness of the transactions without exposing the transaction details, thereby enhancing user privacy protection and transaction security.

[0066] In a specific embodiment, the step of pre-executing each transaction to generate the first state, and / or the step of updating the initial state of each transaction before pre-execution to obtain the updated second state of each transaction is executed by a translation virtual machine. The translation virtual machine is only used to execute transactions, generate the corresponding first state, and / or update to obtain the corresponding second state of each transaction, and the execution efficiency of this step is very high. The above step S13 of parallelly executing multiple transactions based on the updated second state of each transaction and recording the execution traces of each transaction during parallel execution is executed by at least two interpretation virtual machines.

[0067] It should be noted that in the existing method, since there may be dependency relationships between the initial states of each transaction, in order to correctly execute each transaction, generally, an interpretation virtual machine is directly used to serially execute multiple transactions based on the initial states of each transaction and record the execution traces of each transaction during serial execution. Among them, recording the execution traces is time-consuming, resulting in a long time required from executing the transactions to generating the proofs.

[0068] In this embodiment, since there are no dependency relationships between the second states of each transaction obtained in step S12, the second virtual machine can parallelly execute multiple transactions based on the second states of each transaction and record the execution traces of each transaction during parallel execution. The efficiency of both transaction execution and recording the execution traces is greatly improved, thereby significantly improving the efficiency from transaction execution to proof generation.

[0069] By comparing the execution efficiency of this embodiment and the above existing method, in this embodiment, the translation virtual machine is used to pre-execute the transactions to obtain the first state, and / or update to obtain the corresponding second state of each transaction, and the method of using at least two interpretation virtual machines to execute step S13 proves that the generation efficiency is about 400 times higher than that of the prior art.

[0070] Please refer to Figure 3 , Figure 3 is a schematic framework diagram of an embodiment of the electronic device provided by this application. In this embodiment, the electronic device 30 includes a memory 31 and a processor 32 that are coupled to each other.

[0071] The memory 31 stores program instructions, and the processor 32 is configured to execute the program instructions stored in the memory 31 to implement the steps of any of the above method embodiments. In a specific implementation scenario, the electronic device 30 may include, but is not limited to, a microcomputer, a server. In addition, the electronic device 30 may also include mobile devices such as laptop computers, tablet computers, etc., which are not limited herein.

[0072] Specifically, the processor 32 is configured to control itself and the memory 31 to implement the steps of any of the above embodiments. The processor 32 may also be referred to as a CPU (Central Processing Unit). The processor 32 may be an integrated circuit chip with signal processing capabilities. The processor 32 may also be a general-purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc. Additionally, the processor 32 may be implemented jointly by integrated circuit chips.

[0073] Please refer to Figure 4 , Figure 4 , which is a schematic framework diagram of the computer-readable storage medium provided by this application. The computer-readable storage medium 40 of the embodiments of this application stores program instructions 41, and when the program instructions 41 are executed, the methods provided by any one of the above embodiments and any non-conflicting combinations are implemented. Among them, the program instructions 41 may form a program file and be stored in the above computer-readable storage medium 40 in the form of a software product, so that a computer device (which may be a personal computer, a server, or a network device, etc.) can execute all or part of the steps of the methods of various embodiments of this application. The aforementioned computer-readable storage medium 40 includes: various media that can store program codes such as USB flash drives, mobile hard disks, read-only memories (ROM, Read-Only Memory), random access memories (RAM, Random Access Memory), magnetic disks, or optical discs, or terminal devices such as computers, servers, mobile phones, and tablets.

[0074] In the above solution, the initial state of each transaction before pre-execution is updated by the first state generated during the pre-execution of each transaction and the dependency relationships among multiple transactions, so as to obtain the corresponding updated second state, such that there are no dependency relationships among the second states of each transaction. Furthermore, based on the updated second states of each transaction, multiple transactions are executed in parallel (at this time, there are no dependency relationships among the transaction executions), and the execution traces of each transaction during parallel execution are recorded. Then, corresponding proofs are generated based on the execution traces corresponding to each transaction. Compared with the method of generating the execution traces of transaction executions by using a serial execution method, the above solution of the present application can pre-solve the dependencies among transactions, thereby enabling the transactions to be executed in parallel, and recording the execution traces corresponding to each transaction in parallel, which can significantly improve the efficiency of obtaining the execution traces of each transaction, and further improve the efficiency of proof generation and the efficiency of the entire transaction verification.

[0075] The descriptions of the above embodiments tend to emphasize the differences among the embodiments. The similarities or similarities among them can be referred to each other. For the sake of brevity, they will not be elaborated herein.

[0076] The above are only the embodiments of the present application, and do not limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made by using the content of the specification and drawings of the present application, or directly or indirectly applied to other related technical fields, shall be equally included in the patent protection scope of the present application.

Claims

1. A method for generating a certificate, characterized in that: The method comprises: Acquire multiple transactions stored in a block; there is a dependency relationship between the initial states of the multiple transactions; Based on the first state generated by each transaction during pre-execution and the dependency relationship between the multiple transactions, the initial state of each transaction before the pre-execution is updated to obtain the updated second state of each transaction; wherein there is no dependency relationship between the second states of each transaction; executing the plurality of transactions in parallel based on the second status updated by each transaction, and recording the execution track of each transaction during the parallel execution; Generate proofs based on the execution traces corresponding to each transaction.

2. The method according to claim 1, characterized in that The updating of the initial state of each transaction before the pre-execution based on the first state generated during the pre-execution of each transaction and the dependency relationship between the multiple transactions to obtain the updated second state of each transaction includes: Executing each of the transactions in sequence according to a pre-execution order of the multiple transactions to obtain the first state of each of the transactions; wherein the pre-execution order is determined by using a dependency relationship between initial states of the multiple transactions; The initial state of the first transaction is used as the second state of the first transaction, and the first state of the previous transaction having a dependency relationship with the non-first transaction is used to update the second state of the non-first transaction.

3. The method according to claim 2, characterized in that The step of sequentially executing each of the transactions according to the pre-execution order of the multiple transactions to obtain the first state of each of the transactions is performed by a first virtual machine, wherein the first virtual machine includes a translation type virtual machine; And / or, the step of executing the plurality of transactions in parallel based on the second state updated by each transaction and recording the execution track of each transaction during the parallel execution is performed by a second virtual machine, and the second virtual machine is an interpreted virtual machine.

4. The method according to claim 1, characterized in that: The step of executing the plurality of transactions in parallel based on the second state updated by each transaction and recording the execution track of each transaction during the parallel execution is performed by at least two second virtual machines; Before executing the plurality of transactions in parallel based on the second state updated by each transaction and recording the execution track of each transaction during the parallel execution, the method further includes: Finding the associated instructions of each of the transactions from a plurality of instructions in a target execution object; the target execution object is used to execute a plurality of the transactions in the block, and the plurality of instructions are obtained by parsing the target execution object; Allocate a plurality of the transactions and corresponding associated instructions to at least two of the second virtual machines; wherein each of the second virtual machines is allocated at least one of the transactions.

5. The method according to claim 4, characterized in that The executing the plurality of transactions in parallel based on the second state updated by each transaction, and recording the execution track of each transaction during the parallel execution, includes: Utilizing each of the second virtual machines to execute the corresponding transactions in parallel based on the associated instructions of the allocated transactions and the corresponding second states, and recording the execution track of each transaction during the parallel execution; The execution trace includes the register value and memory status information of the corresponding second virtual machine recorded during the execution of the corresponding transaction by the associated instructions; the proof is used to prove whether the execution process of the associated instructions of each transaction for the corresponding transaction is correct.

6. The method according to claim 4, characterized in that The allocating the plurality of transactions and the corresponding associated instructions to at least two of the second virtual machines comprises: Based on the current load status data of each second virtual machine, transactions and associated instructions corresponding to the transactions are allocated to each second virtual machine; wherein the load status data is negatively correlated with the number of allocated transactions.

7. The method according to claim 4, characterized in that The steps of finding the associated instructions of each of the transactions from the plurality of instructions in the target execution object, and allocating the plurality of transactions and the corresponding associated instructions to the at least two first virtual machines are performed by the third virtual machine; The second virtual machine and the third virtual machine are virtual machines of the same type, and the third virtual machine is or is not one of the at least two second virtual machines.

8. The method according to claim 1, characterized in that The proof is generated based on the execution trace corresponding to each transaction, including: Merge the execution traces corresponding to each transaction to obtain the target execution trace; The proof is generated using the target execution trajectory.

9. An electronic device, characterized in that: comprising a memory and a processor coupled to each other, The memory stores program instructions; The processor is used to execute the program instructions stored in the memory to implement the method according to any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores program instructions that can be run by a processor, and the program instructions can be executed by the processor to implement the method according to any one of claims 1 to 8.

Images