A contract certificate consistency verification method, device and electronic equipment

Abstract

This disclosure provides a method, apparatus, electronic device, and readable medium for verifying the consistency of contract credentials. The method includes: acquiring contract credentials generated by a smart contract operation and management system within the current time window; grouping the contract credentials according to their corresponding contract instances, sorting the contract credentials within each group, and calculating the hash value of each contract credential; constructing a Merkle tree for each contract instance using a predetermined number of branching tree structures and calculating the current verification Merkle root; acquiring the current baseline Merkle root sent by the smart contract operation and management system for that contract instance; and comparing the current verification Merkle root with the current baseline Merkle root to verify the consistency of the contract credentials. This disclosure enables consistency verification of contract credentials among various entities in a centralized system, thereby ensuring the traceability and immutability of transactions and improving transaction security.

Description

Technical Field

[0001] This disclosure relates to the field of smart contract technology, specifically to a method, apparatus, electronic device, and readable medium for verifying the consistency of contract credentials. Background Technology

[0002] When smart contracts are applied in decentralized systems such as blockchain, the following mechanisms ensure the verifiability and immutability of the contracts: During smart contract deployment, the deployment transaction is signed to prevent tampering. After being broadcast across the node network, the deployment transaction requires network-wide confirmation via a consensus algorithm before being written into the blockchain, becoming part of the blockchain history. The contract code cannot be modified. The contract address corresponding to the contract code is generated from the deployer's address and the deployer's transaction count (Nonce). Once the contract address is generated, the code is bound to the address, preventing the redeployment of other code at that address. Subsequent access to the contract can be completed through the contract address. During smart contract invocation, nodes need to reproduce the transaction logic in an execution environment such as a virtual machine (EVM or JVM), and the transaction also requires node consensus, thus ensuring the verifiability and immutability of the transaction.

[0003] However, in some scenarios, due to specific regulatory requirements, smart contracts cannot be deployed in decentralized systems. For example, highly regulated sectors such as finance and healthcare require pre-deployment review by a centralized institution. During contract execution, a centralized institution may also be needed to manage and verify the contracts, preventing tampering with the contract code or execution results by different entities. Existing decentralized architectures such as blockchains present technical challenges for regulatory intervention, hindering their large-scale application in specific industries. Furthermore, decentralized systems require transactions to be re-run across all nodes and consensus reached on the state tree of the execution results, resulting in lower execution efficiency and failing to meet the timeliness requirements of high-frequency trading.

[0004] Therefore, how to build a contract certificate consistency verification framework in a centralized system that does not require trust assumptions, while retaining the traceability and tamper-proof characteristics of traditional decentralized systems and overcoming their performance and regulatory compatibility bottlenecks, has become a key issue restricting the development of smart contract technology. Summary of the Invention

[0005] This disclosure provides a method, apparatus, electronic device, and readable medium for verifying the consistency of contract credentials in a centralized system. This enables consistency verification of contract credentials for smart contract execution among various entities, thereby ensuring the traceability and immutability of transactions and improving transaction security.

[0006] To achieve the above technical objectives, the embodiments of this disclosure adopt the following technical solutions:

[0007] In a first aspect, embodiments of this disclosure provide a method for verifying the consistency of contract credentials, applied to a smart contract service platform, the method comprising:

[0008] Obtain the contract credentials generated by the smart contract operation and management system within the current time window;

[0009] The contract vouchers are grouped according to their corresponding contract instances, the contract vouchers within each group are sorted, and the hash value of each contract voucher is calculated.

[0010] For each contract instance, a Merkle tree is constructed with a set number of branching tree structures. If the current time window is the first time window, the first leaf node is the hash value of a specific string; if the current time window is not the first time window, the first leaf node is the preorder Merkle root of the contract instance in the previous time window; starting from the second leaf node, the hash values ​​of the calculated contract credentials are added to the bottom of the Merkle tree in sequence.

[0011] Select the hash values ​​of the leaf nodes in sequence according to the set number to calculate the hash value of the parent node; repeat the following operations until the current verification Merkle root is obtained: use the calculated parent node hash value as the hash value of the next layer of leaf nodes, calculate the new parent node hash value, until the number of parent node hash values ​​is 1;

[0012] Obtain the current baseline Merkle root generated from the contract credentials for this contract instance based on the current time window sent by the smart contract operation and management organization system;

[0013] Compare the current verification Merkle root with the current benchmark Merkle root to verify the consistency of the contract credentials.

[0014] In some possible implementations, before calculating the hash value of each contract credential, the method further includes: selecting values ​​from predefined fields in the contract credential, concatenating them in a fixed order, and calculating the hash value of the concatenated string, wherein the predefined fields include one or more of the following:

[0015] Contract instance identifier, contract certificate identifier, smart contract operation and management organization identifier, contract instruction execution sequence number, contract wallet identifier, contract wallet operation record, contract storage operation record, oracle operation record.

[0016] In some possible implementations, the method further includes: assembling the current verification Merkle root obtained from each contract instance to obtain a verification data structure table;

[0017] Obtain the current benchmark Merkle root sent by the smart contract operation and management organization system, including: obtaining the benchmark data structure table generated based on the current benchmark Merkle root sent by the smart contract operation and management organization system;

[0018] The consistency of the contract certificate is verified by comparing the current verification Merkle root with the current benchmark Merkle root, including comparing the verification data structure table and the benchmark data structure table to obtain the comparison results of the current verification Merkle root and the current benchmark Merkle root, thereby verifying the consistency of the contract certificate.

[0019] In some possible implementations, comparing the verification data structure table and the benchmark data structure table includes: both the verification data structure table and the benchmark data structure table are assembled sequentially according to the contract instance identifier, and the hash values ​​of the verification data structure table and the benchmark data structure table are calculated respectively to compare the consistency of the data between the two.

[0020] In some possible implementations, the verification data structure table and the baseline data structure table also include the number of contract vouchers;

[0021] Before comparing the current verification Merkle root with the current benchmark Merkle root, the method also includes:

[0022] Compare and verify whether the number of contract vouchers in the verification data structure table and the benchmark data structure table are consistent.

[0023] In some possible implementations, the method further includes:

[0024] If the current time window is not the first time window, it is determined that the preceding verification Merkle root obtained from the previous time window and the obtained preceding benchmark Merkle root have been verified to be consistent, and the preceding verification Merkle root or the preceding benchmark Merkle root is taken as the preceding Merkle root.

[0025] In some possible implementations, the method further includes: determining that the transaction backtracking verification of each contract certificate generated within the previous time window has passed.

[0026] In some possible implementations, the hash value of the obtained parent node is used as the hash value of the next level leaf node, and a new parent node hash value is calculated until the number of parent node hash values ​​is 1, including:

[0027] If the number of parent node hash values ​​obtained in the current calculation is 1, then the current check Merkle root is the parent node hash value.

[0028] If the number of parent node hash values ​​obtained by the current calculation is greater than 1, then the calculated parent node hash value is used as the hash value of the next layer of leaf nodes. The new parent node hash value is calculated by selecting the leaf node hash value of the next layer in turn according to the set number, until the number of parent node hash values ​​is 1. The parent node hash value when the number of parent node hash values ​​is 1 is used as the current verification Merkle root.

[0029] In some possible implementations, if the current verification Merkle root is inconsistent with the current benchmark Merkle root, a verification result indicating a consistency verification failure is sent to the smart contract operation and management system.

[0030] In some possible implementations, the method further includes: receiving an updated contract certificate sent by the smart contract operation and management system based on the verification result, obtaining the Merkel path and recalculating the hash value of the contract certificate, and replacing the hash value of the original leaf node with the hash value based on the recalculated hash value to calculate a new current verification Merkel root according to the Merkel path.

[0031] Compare the new current validation Merkle root with the current benchmark Merkle root to verify the consistency of the contract credentials.

[0032] Secondly, this disclosure provides a method for verifying the consistency of contract credentials, applied to a smart contract operation and management system. The method includes:

[0033] Execute the contract instance, generate and send the contract credentials so that the smart contract service platform can calculate and obtain the current verification Merkle root;

[0034] Select contract credentials generated within the current time window, group them according to their corresponding contract instances, sort the contract credentials within each group, and calculate the hash value of each contract credential.

[0035] For each contract instance, a Merkle tree is constructed with a set number of branching tree structures. If the current time window is the first time window, the first leaf node is the hash value of a specific string; if the current time window is not the first time window, the first leaf node is the preorder Merkle root of the contract instance in the previous time window; starting from the second leaf node, the hash values ​​of the calculated contract credentials are added to the bottom of the Merkle tree in sequence.

[0036] Select the hash values ​​of the leaf nodes in sequence according to the set number to calculate the hash value of the parent node; repeat the following operations until the current baseline Merkle root is obtained: use the calculated parent node hash value as the hash value of the next layer of leaf nodes, calculate the new parent node hash value, until the number of parent node hash values ​​is 1;

[0037] Send the current benchmark Merkle root so that the smart contract service platform can compare the current benchmark Merkle root with the current verification Merkle root to verify the consistency of the contract certificate.

[0038] In some possible implementations, the method further includes, before calculating the hash value of each contract credential:

[0039] The values ​​of predefined fields selected from the contract document are concatenated in a fixed order, and the hash value of the concatenated string is calculated. The predefined fields include one or more of the following:

[0040] Contract instance identifier, contract certificate identifier, smart contract operation and management organization identifier, contract instruction execution sequence number, contract wallet identifier, contract wallet operation record, contract storage operation record, oracle operation record.

[0041] In some possible implementations, the current benchmark Merkle root calculated for each contract instance is assembled to obtain and send the benchmark data structure table.

[0042] In some possible implementations, the baseline data structure table also includes the number of contract vouchers.

[0043] In some possible implementations, the hash value of the obtained parent node is used as the hash value of the next level leaf node, and a new parent node hash value is calculated until the number of parent node hash values ​​is 1, including:

[0044] If the number of parent node hash values ​​obtained in the current calculation is 1, then the current base Merkle root is the parent node hash value;

[0045] If the number of parent node hash values ​​obtained by the current calculation is greater than 1, then the calculated parent node hash value is used as the hash value of the next layer of leaf nodes. The new parent node hash value is calculated by selecting the leaf node hash value of the next layer in turn according to the set number, until the number of parent node hash values ​​is 1. The parent node hash value when the number of parent node hash values ​​is 1 is used as the current baseline Merkle root.

[0046] In some possible implementations, if the current verification Merkle root and the current benchmark Merkle root are inconsistent, a consistency verification failure result sent by the smart contract service platform is received.

[0047] In some possible implementations, the method further includes sending an updated contract credential based on the verification result.

[0048] Thirdly, this disclosure provides a contract certificate consistency verification device applied to a smart contract service platform, the device comprising:

[0049] The platform's sending and receiving module is configured to obtain contract credentials generated by the smart contract operation and management system within the current time window;

[0050] The platform's hash calculation module is configured to group contract credentials according to their corresponding contract instances, sort the contract credentials within each group, and calculate the hash value of each contract credential.

[0051] The platform's Merkle root generation module is configured to construct a Merkle tree for each contract instance using a set number of branching tree structures. If the current time window is the first time window, the first leaf node is the hash value of a specific string; if the current time window is not the first time window, the first leaf node is the preorder Merkle root of the contract instance in the previous time window. Starting from the second leaf node, the calculated hash values ​​of contract credentials are sequentially added to the bottom of the Merkle tree. The hash values ​​of leaf nodes are selected sequentially according to a set number to calculate the parent node hash value. The following operations are repeated until the current verification Merkle root is obtained: using the calculated parent node hash value as the hash value of the next layer of leaf nodes, a new parent node hash value is calculated until the number of parent node hash values ​​is 1.

[0052] The platform's sending and receiving module is also configured to obtain the current benchmark Merkle root generated by the contract certificate based on the current time window sent by the smart contract operation and management agency system for the contract instance;

[0053] The platform verification module is configured to compare the current verification Merkle root with the current benchmark Merkle root to verify the consistency of the contract credentials.

[0054] Fourthly, this disclosure provides a contract certificate consistency verification device, applied to a smart contract operation and management system, the device comprising:

[0055] The contract execution module is configured to execute contract instances, generate and send contract credentials so that the smart contract service platform can calculate and obtain the current verification Merkle root;

[0056] The institutional hash calculation module is configured to select contract credentials generated within the current time window, group them according to their corresponding contract instances, sort the contract credentials within each group, and calculate the hash value of each contract credential.

[0057] The Merkle root generation module is configured to construct a Merkle tree for each contract instance using a set number of branching tree structures. If the current time window is the first time window, the first leaf node is the hash value of a specific string; if the current time window is not the first time window, the first leaf node is the preorder Merkle root of the contract instance in the previous time window. Starting from the second leaf node, the calculated hash values ​​of contract credentials are sequentially added to the bottom of the Merkle tree. The hash values ​​of leaf nodes are sequentially selected according to a set number to calculate the parent node hash value. The following operations are repeated until the current baseline Merkle root is obtained: using the calculated parent node hash value as the hash value of the next layer of leaf nodes, a new parent node hash value is calculated until the number of parent node hash values ​​is 1.

[0058] The institution's sending and receiving module is configured to send the current benchmark Merkle root so that the smart contract service platform can compare the current benchmark Merkle root with the current verification Merkle root to verify the consistency of the contract certificate.

[0059] Fifthly, embodiments of this application provide an electronic device, including: one or more processors; and a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the methods as described in the first aspect, the second aspect, and so on.

[0060] Sixthly, embodiments of this application provide a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the methods of the first and second aspects.

[0061] The technical solution of the first aspect provided by the embodiments of this disclosure brings at least the following beneficial effects: The method of the embodiments of this disclosure includes obtaining contract credentials generated by the smart contract operation and management system within the current time window; grouping the contract credentials according to their corresponding contract instances, sorting the contract credentials within each group, and calculating the hash value of each contract credential; constructing a Merkle tree with a set number of branching tree structures for each contract instance and calculating the current verification Merkle root; obtaining the current benchmark Merkle root sent by the smart contract operation and management system for the contract instance; and comparing the current verification Merkle root and the current benchmark Merkle root to verify the consistency of the contract credentials. Therefore, the embodiments of this disclosure generate Merkle trees for the contract credentials generated by each contract instance within the same time period between the smart contract operation and management system and the smart contract service platform, and realize the consistency verification of the contract credentials corresponding to each contract instance by comparing the Merkle roots; at the same time, by writing the preceding Merkle root as the first leaf node into the current Merkle tree, the traceability and immutability of historical transactions are guaranteed, and transaction security is improved.

[0062] It should be noted that the technical effects of any of the implementation methods in aspects two through six can be found in the technical effects of the corresponding implementation methods in aspect one, and will not be repeated here.

[0063] The further effects of the aforementioned unconventional alternative methods will be explained below in conjunction with specific implementation methods. Attached Figure Description

[0064] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings of the embodiments of this disclosure will be briefly described below. Clearly, the drawings described below only relate to some embodiments of this disclosure and are not intended to limit the scope of this disclosure.

[0065] Figure 1 A schematic diagram of a contract certificate consistency verification system according to at least one embodiment of the present disclosure is shown;

[0066] Figure 2 A schematic diagram illustrating the main steps of a contract certificate consistency verification method according to at least one embodiment of the present disclosure is shown.

[0067] Figure 3 A schematic diagram illustrating the main steps of a contract certificate consistency verification method according to at least one embodiment of the present disclosure is shown.

[0068] Figure 4 A flowchart of a contract certificate consistency verification method according to at least one embodiment of the present disclosure is shown;

[0069] Figures 5A-5B A schematic diagram of a Merklegen calculation method according to at least one embodiment of the present disclosure is shown;

[0070] Figure 6 A schematic diagram of the main modules of a contract document consistency verification device according to at least one embodiment of the present disclosure is shown;

[0071] Figure 7 A schematic diagram of the main modules of a contract document consistency verification apparatus according to at least one embodiment of the present disclosure is shown;

[0072] Figure 8 A schematic diagram of an electronic device according to at least one embodiment of the present disclosure is shown;

[0073] Figure 9 A schematic diagram of a computer-readable medium according to at least one embodiment of the present disclosure is shown. Detailed Implementation

[0074] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this disclosure. All other embodiments obtained by those skilled in the art based on the described embodiments of this disclosure without creative effort are within the scope of protection of this disclosure.

[0075] In the following text, any methods, apparatus, examples, and contents that do not fully correspond to the scope defined by the claims are not derived from the present invention. Such methods, apparatus, examples, and contents, as well as all subsequent descriptions, are for illustrative purposes only, or to highlight specific aspects or features of the claims.

[0076] Note that the examples described below are merely specific examples and are not intended to limit the embodiments of this disclosure to the specific shapes, hardware, connections, operations, values, conditions, data, sequences, etc., shown and described. Those skilled in the art can utilize the concepts of this disclosure to construct further embodiments not mentioned herein by reading this specification.

[0077] The terminology used in this disclosure is that which is currently widely used in the art in consideration of the functionality of this disclosure; however, these terms may vary depending on the intent, precedent, or new technology of those skilled in the art. Furthermore, specific terms may be chosen by the applicant, and in such cases, their detailed meanings will be described in the detailed description of this disclosure. Therefore, the terminology used in this specification should not be construed as simple names, but rather based on the meaning of the terms and the overall description of this disclosure.

[0078] To better understand the embodiments of this disclosure, the relevant terms involved in this disclosure will first be defined and explained.

[0079] A smart contract is a self-executing computer program that automatically executes its terms when preset conditions are met. Smart contracts typically contain a set of predefined rules, according to which the parties involved agree to interact with each other.

[0080] A contract instance refers to a specific smart contract object deployed and running in a centralized or decentralized system (such as a blockchain). A contract instance is generated when a developer deploys smart contract code to a system. Each contract instance has a unique contract address, which users can use to interact with the contract, call functions within the contract, or query state variables.

[0081] Contract credentials refer to supporting documents or data related to smart contracts, used to prove that the deployment, execution, or modification of the contract is authentic and valid. For example, in some decentralized application scenarios, contract credentials may include transaction hashes, block information, signatures, etc.

[0082] It should be noted that the technical solutions in this disclosure, including the collection, updating, analysis, processing, use, transmission, and storage of user personal information, all comply with relevant laws and regulations, are used for legitimate purposes, and do not violate public order and good morals. Necessary measures are taken to prevent unauthorized access to user personal information data and to safeguard user personal information security, network security, and national security.

[0083] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0084] Figure 1 A schematic diagram of a contract credential consistency verification system according to at least one embodiment of this disclosure is shown. The system includes a smart contract central management organization 110 and a smart contract operation management organization 120. The smart contract operation management organization system is a computer system or server managed by the smart contract operation management organization 120. The smart contract operation management organization 120 interacts with other systems through this computer system or server. The distinction between the smart contract operation management organization 120 and the smart contract operation management organization system will not be made hereafter. The smart contract central management organization 110 is responsible for the unified registration and management of master data such as smart contract templates, contract products, contract instances, and contract wallets. It provides transfer control services such as mandatory checks and validity checks, and subsequently verifies the consistency of smart contract code execution through contract credentials to ensure the mandatory nature and consistency of smart contracts. It may be, for example, a central bank or other centralized smart contract review, management, and supervision organization. The smart contract operation management organization 120 is an operating organization that builds, manages, and maintains the operating environment according to standards. For example, in a central bank digital currency system, it is an operating organization (under the digital currency system, commercial banks and other financial institutions that participate in the operation of digital currency and provide exchange and circulation services to the public).

[0085] The smart contract central management organization 110 is a centralized organization, while the smart contract operation management organization 120 can be one or more (three are shown in the diagram: organization A, organization B, and organization C), thereby achieving centralized management of the smart contract central management organization 110 and distributed operation of the smart contract operation management organization 120. The smart contract operation management organization 120 includes a smart contract runtime environment and a core system (not shown in the diagram). The core system provides underlying digital currency capabilities such as accounting, payment, and wallet management. The smart contract runtime environment can manage contract templates, contract products, and contract instances approved by the smart contract central management organization 110 in a hierarchical manner. When a smart contract is invoked, the smart contract instance can be loaded into the virtual machine and interact with the core system through the environment interface to complete the transaction.

[0086] The smart contract center management organization 110 may further include a message exchange system 111, a data platform 112, and a smart contract service platform 113. The message exchange system 111, as the communication hub of the smart contract center management organization 110, is responsible for handling the reception, parsing, forwarding, and response to various messages. It can interface with external systems to achieve efficient data transmission and interaction. For example, in a central bank digital currency system, the message exchange system 111 may include a digital currency interconnection system (hereinafter referred to as the interconnection system), which is a platform supporting the transfer, clearing, and message exchange of digital currency / electronic payments between the central bank and various operating institutions, enabling interconnection between the central bank and various operating institutions. Optionally, the message exchange system 111 may further include an API gateway server: deploying gateway tools such as Nginx / Kong to support HTTPS / TLS encrypted communication; and a message middleware cluster: such as Kafka or RabbitMQ, for asynchronous message queue processing, etc. Data platform 112 provides storage, verification, and processing of smart contract lifecycle data, and protects data privacy. This data includes smart contract code, state, transaction records, and related business data. It needs high reliability and availability to ensure data integrity and security. Simultaneously, the data platform provides data query and analysis functions, supports auditing and risk control of smart contract operation status, and its hardware includes high-performance storage devices, servers, and network switches, such as IPFS or Hadoop clusters, supporting petabyte-level data storage. Smart contract service platform 113 implements full-process management of contract development, deployment, execution, and monitoring. It reviews contract templates, contract products, and contract instances before deployment, performs mandatory and validity checks during contract execution, and verifies the consistency of contract credentials and performs transaction backtracking after execution to ensure transaction security. Its hardware includes, for example, smart contract virtual machine clusters (such as EVM or JVM) and sandbox servers (a containerized environment based on Kubernetes).

[0087] After a contract instance is deployed in the smart contract operation and management organization 120, users can generate contract credentials by executing the contract instance. The contract credentials are sent to the message interaction system 111 via a synchronization message. Upon receiving the synchronization message, the message interaction system 111 performs necessary format checks and then forwards it to the data platform 112 for storage. The smart contract service platform 113 retrieves the contract credentials data from the data platform 112 for consistency checks and subsequent transaction backtracking verification. If problems are found during consistency checks or transaction backtracking verification, the smart contract service platform 113 can send the problem to the message interaction system 111 and further report it to the corresponding smart contract operation and management organization 120. Therefore, this embodiment provides cross-organizational contract credentials consistency verification capabilities and the expansion capabilities of multiple smart contract operation and management organizations 120. It is understood that, based on the scheme of this embodiment, after a contract instance is reviewed by the smart contract center management organization 110, it is deployed in the smart contract operation and management organization 120. The smart contract operation and management organization 120 sends the contract certificate generated after executing the contract instance to the smart contract center management organization 110. By comparing the Merkle root generated by the two organizations based on the contract certificate, it can be confirmed whether the contract certificates are consistent, such as whether any omissions occurred during the transmission of the contract certificate.

[0088] Figure 2 A schematic diagram illustrating the main steps of a contract credential consistency verification method S200 according to at least one embodiment of the present disclosure is shown. This method is applied to the smart contract service platform 113 of a smart contract central management institution 110 and includes the following main steps:

[0089] Step S210: Obtain the contract certificate generated by the smart contract operation and management organization 120 within the current time window. Before starting step S210, the smart contract center management organization 110 and the smart contract operation and management organization 120 can agree on a time period for contract certificate consistency verification (e.g., one day, with each day from 0:00 to 24:00 as a time window), or agree on several time nodes (e.g., 0:00 on the 1st, 10th, and 20th of each month as time nodes, or 0:00, 8:00, and 16:00 each day as time nodes, with the time between two time nodes as a time window). The time nodes can be evenly distributed over time, or they can be flexibly adjusted according to the generation of contract certificates, but an agreement must be reached between the smart contract center management organization 110 and the smart contract operation and management organization 120.

[0090] When a smart contract operation and management organization 120 (e.g.) Figure 2After deploying a contract instance, users can execute smart contracts by calling the execution instance. Contract transactions fall into two categories: first, intra-institutional transactions. If the transaction instruction of the smart contract is an intra-institutional transaction instruction (i.e., the smart contract operation and management institution 120 can execute the smart contract independently), the smart contract can be executed directly, generating contract credentials. Second, cross-institutional transactions. If the transaction instruction of the smart contract is a cross-institutional transaction instruction (i.e., the smart contract operation and management institution 120 cannot execute the smart contract independently, for example, the transaction involves contract wallets managed by other smart contract operation and management institutions 120, such as a transfer operation from a user wallet of institution A to a user wallet of institution B), then institution A sends a cross-institutional transaction request to the message interaction system 111, which forwards it to the smart contract center management institution 110. Once the smart contract central management agency 110 approves the cross-institutional transaction request, it forwards the request to other smart contract operation and management agencies 120 (e.g., Agency B) via the message exchange system 111. The other smart contract operation and management agency 120 generates a cross-institutional transaction response based on the request and sends it back to Agency A via the message exchange system 111. At this point, Agency A completes contract execution and can generate a contract certificate.

[0091] Once the contract certificate is generated, it can be sent to the message interaction system 111 via an information synchronization message. After receiving the information synchronization message, the message interaction system 111 performs necessary format checks and then forwards it to the data platform 112 for storage. The smart contract service platform 113 of the smart contract center management organization 110 can retrieve contract certificate data from the data platform 112 at any time for contract certificate consistency checks and subsequent transaction backtracking verification. It is understood that when the smart contract center management organization 110 needs to perform consistency verification on contract certificates generated within the current time window, it can retrieve the relevant contract certificate data from the data platform 112 all at once, or it can retrieve it at any time after the contract certificate data has been stored in the database and save it locally. The method and timing of contract certificate acquisition are not limited in this disclosure.

[0092] Optionally, to ensure that the smart contract center management organization 110 can perform subsequent transaction backtracking on the contract execution results of the smart contract operation management organization 120, the contract certificate may include necessary verification fields, and the contract certificate may be transmitted in a data format commonly used in the field based on the field information it includes.

[0093] To perform subsequent hash calculations, values ​​from predefined fields can be selected from the contract certificate and concatenated in a fixed order to obtain a concatenated string. The hash value of this concatenated string is then calculated. The predefined fields can include one or more of the following: contract instance identifier (contract instance ID), contract certificate identifier (contract certificate ID), smart contract operation management organization identifier (organization ID), contract instruction execution sequence number, contract wallet identifier (contract wallet ID), contract wallet operation record, contract storage operation record, and oracle operation record. These predefined fields can be expanded as needed for consistency verification. It is understood that the selection and order of the predefined fields must be consistent between the smart contract central management organization 110 and the smart contract operation management organization 120 to ensure that the hash value calculated for the string is the same.

[0094] Here's an example of the concatenation method: Select values ​​from predefined fields in the data of each contract credential and concatenate them sequentially using the "|" symbol. There may be multiple records for contract wallet operation records, contract storage operation records, and oracle operation records. If multiple records exist, sort them in ascending order by their respective numbers, concatenate each record, and then use the "|" symbol to concatenate them into a single string. Finally, use an algorithm (e.g., SM3) to calculate the hash value of the concatenated string. Even if a data field is empty, it still occupies one "|" concatenation symbol.

[0095] Below is an example of a predefined field concatenation rule:

[0096] Predefined field concatenation rules: Contract Certificate ID | Institution ID | Contract Instance ID | Contract Instruction ID | Parent Contract Instruction ID | Initiator Extended ID | Executor Extended ID | Instruction Action Type | Contract Call Method Name | Contract Call Input Data | Attached Amount | Contract Callback Parameters | Contract Instruction Response Error Code | Contract Instruction Response Error Detailed Description | Contract Wallet ID | Contract Wallet Operation Record | Contract Storage Operation Record | Oracle Operation Record | Contract Instruction Execution Sequence Number | Certificate Time.

[0097] The contract wallet operation records, contract storage operation records, and oracle operation records mentioned above may further include:

[0098] Contract wallet operation log: Contract wallet ID | Operation type | Operation amount | Sequence number.

[0099] Contract storage operation record: Contract instance ID | Operation type | Data key | Data value | Sequence number.

[0100] Oracle operation log: Oracle data type | Oracle input data | Oracle output data | Sequence number.

[0101] The following is a sample data of a contract certificate string generated according to the above concatenation rules:

[0102] 000000000000000011111111111111111110|00000002231230|0000000000000000000000000000000001324321211111111111111111111232|0000000000000000 00000000000000002331111111111111111111111111111|00000000000000000 0000000000000002331111111111111111111110000000|||0|transfer|111111 1111|123|111233333|E001|error|1111000000000011|1111000000000011|2| 123|11000000000000000000000000000000000000000000000000000000000 00|000000000000000000000000000000001324321211111111111111111111123 2|2|key|value|1111110|1|123|321|1111110|111111111111|1721116146383.

[0103] In step S220, the smart contract service platform 113 of the smart contract center management organization 110 groups the contract credentials according to their corresponding contract instances, sorts the contract credentials in each group, and calculates the hash value of each contract credential.

[0104] It is understandable that the smart contract center management organization 110 will receive contract credentials from one or more smart contract operation management organizations 120 within the current time window, and these contract credentials may be generated by calling different contract instances. Therefore, the smart contract center management organization 110 groups the contract credentials of a smart contract operation management organization 120 (e.g., organization A) within the current time window according to their corresponding contract instances; and sorts them, for example, by sorting the contract credentials of each contract instance according to the contract instruction execution sequence number included in the contract credential field. After sorting, a hash value is calculated for each contract credential, that is, the hash value is calculated for the string obtained by concatenating the contract credentials. Taking the above example of the contract credential string data, the calculated hash value is:

[0105] A5843AD2FACC4144944C4A066ED73AF4C53B3BB3A88F142383C33C5A46578F96.

[0106] Step S230: For each contract instance, construct a Merkle tree with a set number of branching tree structures. If the current time window is the first time window, the first leaf node is the hash value of a specific string. If the current time window is not the first time window, the first leaf node is the preorder Merkle root of the contract instance in the previous time window. Starting from the second leaf node, add the calculated hash values ​​of the contract credentials to the bottom of the Merkle tree in sequence.

[0107] Specifically, Figures 5A-5B A schematic diagram of a Merkle root calculation method according to at least one embodiment of the present disclosure is shown. For each contract instance, a Merkle tree is constructed using the hash values ​​of contract credentials sorted for the current time window of that contract instance. Figures 5A-5B Taking a binary Merkle tree as an example, starting from the second leaf node, the hash values ​​of contract tokens 1 to 7 are added sequentially (Hash0-0-1 to Hash 1-1-1) to the bottom of the Merkle tree (i.e., the lowest leaf node level). Contract tokens 1 to 7 are already sorted, for example, according to the order of contract instruction execution. Optionally, besides choosing a binary Merkle tree structure with a set number of branches (2), a multi-branch tree can also be chosen, such as a multi-branch tree structure with a set number of branches (3 or 4). In a binary tree structure, two leaf nodes calculate one parent node; in a multi-branch tree structure, multiple leaf nodes calculate one parent node.

[0108] Understandably, for a single contract instance, one could choose not to divide the time window and instead construct a Merkle tree from all contract credentials for that instance. However, to prevent the overall data volume of the Merkle tree from becoming excessive and to avoid redundant verification of already compared data, this embodiment compresses and integrates the data. Specifically, each contract instance is generated using contract credential data within a single time window as a separate Merkle tree, and the first leaf node of each subsequent tree is the root hash value of the Merkle tree corresponding to the previous time window. Therefore, if the current time window is the first time window, the first leaf node is the hash value of a specific string, such as the hash value of an empty string; if the current time window is not the first time window, the first leaf node is the preorder Merkle root of that contract instance within the previous time window.

[0109] Step S240: Select the hash values ​​of the leaf nodes in sequence according to the set number to calculate the hash value of the parent node; repeat the following operations until the current verification Merkle root is obtained: use the calculated parent node hash value as the hash value of the next layer of leaf nodes, calculate the new parent node hash value, until the number of parent node hash values ​​is 1.

[0110] Optionally, if the number of parent node hash values ​​obtained by the current calculation is 1, then the parent node hash value is used as the current verification Merkle root; if the number of parent node hash values ​​obtained by the current calculation is greater than 1, then the calculated parent node hash value is used as the hash value of the next layer leaf node, and the new parent node hash value is calculated by sequentially selecting the leaf node hash value of the next layer according to the set number, until the number of parent node hash values ​​is 1, and the parent node hash value when the number of parent node hash values ​​is 1 is used as the current verification Merkle root.

[0111] Specifically, from Figure 5A As shown in the diagram, taking a binary tree as an example, the hash value of the parent node is calculated by sequentially selecting two adjacent hash values. For example, Hash 0-0 is calculated using Hash 0-0-0 and Hash 0-0-1, Hash 0-1 is calculated using Hash 0-1-0 and Hash 0-1-1, Hash 1-0 is calculated using Hash 1-0-0 and Hash 1-0-1, and Hash 1-1-0 and Hash 1-1-1 are calculated using Hash 1-1-0 and Hash 1-1-1. At this point, the number of parent node hash values ​​is 4. Therefore, the calculated Hash 0-0, Hash 0-1, Hash 1-0, and Hash 1-1 are used as the hash values ​​of the leaf nodes at the next level to calculate the new parent node hash values ​​Hash 0 and Hash 1. At this point, the number of parent node hash values ​​is 2. Continue to use the calculated parent node hash values ​​Hash 0 and Hash 1 as the hash values ​​of the next level leaf nodes to calculate new parent node hash values. At this point, the number of parent node hash values ​​is 1. Therefore, the parent node hash value (root hash value) calculated at this point is the current verification Merkle root.

[0112] Optionally, during the computation of the Merkle tree, if some leaf nodes are missing, the hash value of the preceding leaf node can be used as the hash value of that leaf node. For example, Figure 5B As shown, if contract certificate 7 is empty, the hash value of contract certificate 6 is copied to the hash value of contract certificate 7.

[0113] Optionally, the hash values ​​of each parent node obtained during the Merkle root calculation can be further stored in the "Contract Instance Hash Data Structure". When verifying inconsistencies in the Merkle root later, the "Contract Instance Hash Data Structure" can be sent to the smart contract operation and management organization 120 to improve the efficiency of confirming specific inconsistent contract credentials.

[0114] Step S250: Obtain the current baseline Merkle root generated by the contract certificate based on the current time window for the contract instance sent by the smart contract operation and management organization.

[0115] Understandably, the smart contract operation and management organization 120 also generates the current benchmark Merkle root from the contract credentials of each contract instance generated in the current time window according to the same Merkle tree construction method, and sends the generated current benchmark Merkle root to the smart contract center management organization 110 for consistency verification of the contract credentials.

[0116] Optionally, the current baseline Merkle root generated for each contract instance can be sent individually to the smart contract center management agency 110 via a synchronization message, and the smart contract center management agency 110 will compare them one by one. Contract instances that have not generated contract credentials within a time window may not generate a Merkle tree or send a Merkle root.

[0117] Optionally, the current verification Merkle root calculated for each contract instance can be assembled to obtain a verification data structure table. This way, multiple contract instances can be compared and verified by sending the data table once via a synchronization message, reducing the risk of information loss or leakage during multiple transmissions. The Merkle tree data structure table may include, for example, the contract instance ID and root hash value, and may further include the number of leaf nodes that generated the Merkle tree. The data structure table can include various assembly methods; for example, the values ​​of each Merkle tree data field can be concatenated sequentially using "|" (e.g., contract instance ID|root hash value|number of leaf nodes), and multiple Merkle tree data can be concatenated using "," to ultimately form a complete string. In other words, the smart contract central management organization 110 can assemble and generate the verification data structure table based on the current verification Merkle root.

[0118] At this time, the smart contract operation and management organization 120 also constructs the Merkle tree in the same way and assembles the Merkle tree benchmark data structure table. The smart contract center management organization 110 obtains the benchmark data structure table generated based on the current benchmark Merkle root sent by the smart contract operation and management organization 120. By comparing the verification data structure table and the benchmark data structure table, the comparison results of the current verification Merkle root and the current benchmark Merkle root can be obtained, thereby verifying the consistency of the contract certificate.

[0119] Optionally, the smart contract central management organization 110 and the smart contract operation management organization 120 can also assemble the Merkle root of each contract instance in sequence according to the contract instance ID, and calculate the hash values ​​of the generated verification data structure table and the benchmark data structure table respectively. By comparing whether the hash values ​​are consistent, it is determined whether the contract credentials are completely identical. In other words, both the verification data structure table and the benchmark data structure table are assembled in sequence according to the contract instance identifier, and the hash values ​​of the verification data structure table and the benchmark data structure table are calculated respectively to compare the consistency of the two data. It can be understood that when the hash values ​​are consistent, the contract credentials of all contract instances are consistent; when the hash values ​​are inconsistent, they are compared one by one to determine the Merkle root of the contract instances with different results. This helps to improve the efficiency of consistency verification.

[0120] Step S260: Compare the current verification Merkle root with the current benchmark Merkle root to verify the consistency of the contract certificate. Specifically, if the current verification Merkle root and the current benchmark Merkle root are inconsistent, send a verification result indicating a consistency verification failure to the smart contract operation and management organization 120.

[0121] Optionally, if the hash values ​​of each parent node obtained by the smart contract central management agency 110 during the calculation of the Merkle root have been stored in the "contract instance hash data structure", the "contract instance hash data structure" can be sent to the smart contract operation management agency 120 at the same time as the verification result is fed back to the smart contract operation management agency 120. In this way, the smart contract operation management agency 120 can confirm the specific contract certificate with problems by following the Merkle path formed by the hash values ​​of the parent nodes (the Merkle path is a list of hash values ​​used to connect the leaf nodes of the data to be verified to the Merkle root).

[0122] Optionally, the smart contract central management institution 110 may not send the "contract instance hash data structure." In this case, when the current baseline Merkle root of the smart contract operation management institution 120 is inconsistent with the current verification Merkle root of the smart contract central management institution 110, the smart contract operation management institution 120 needs to determine which specific contract credential is problematic. For example, if the smart contract operation management institution 120 needs to verify... Figure 5A To verify the correctness of Contract Certificate 3, the Merkle path of Contract Certificate 3 is obtained from the smart contract center management organization 110; that is, only the values ​​of Hash0-1-0, Hash0-0, and Hash1 need to be obtained. By calculating the hash of Contract Certificate 3 and adding these three hash values, the final root hash can be calculated. If the root hash calculated at this time matches the current verification Merkle root, then the data of Contract Certificate 3 is correct; if they do not match, Contract Certificate 3 needs to be re-uploaded.

[0123] Furthermore, after the smart contract operation and management organization 120 identifies the problematic hash certificate based on the verification results, it can send an updated contract certificate to the smart contract central management organization 110. Based on the updated contract certificate, the smart contract central management organization 110 obtains the Merkle path and recalculates the hash value of the contract certificate. It then replaces the original leaf node's hash value with the recalculated hash value and calculates a new current verification Merkle root according to the Merkle path. The new current verification Merkle root is further compared with the current baseline Merkle root to verify the consistency of the contract certificate. If they are the same, it indicates that the hash certificate verification is consistent and complete.

[0124] Figure 3 A schematic diagram illustrating the main steps of a contract credential consistency verification method according to at least one embodiment of this disclosure is shown, which is applied to a smart contract operation and management organization 120. It is understood that the smart contract operation and management organization 120 and the smart contract service platform 113 of the smart contract center management organization 110 should use the same time window setting, the same contract credential concatenation method, and the same Merkle tree construction rules during the contract credential consistency verification process. Therefore, Figure 3 Zhongyu Figure 2 The specific implementation details of the corresponding steps are not elaborated here. The steps for the smart contract operation and management organization 120 to verify the consistency of contract credentials specifically include:

[0125] Step S310: Execute the contract instance, generate and send the contract certificate so that the smart contract service platform 110 can calculate and obtain the current verification Merkle root;

[0126] Step S320: Select the contract credentials generated within the current time window, group them according to their corresponding contract instances, sort the contract credentials in each group, and calculate the hash value of each contract credential.

[0127] Step S330: For each contract instance, construct a Merkle tree with a set number of branching tree structures. If the current time window is the first time window, the first leaf node is the hash value of a specific string; if the current time window is not the first time window, the first leaf node is the preorder Merkle root of the contract instance in the previous time window; starting from the second leaf node, add the calculated hash values ​​of the contract credentials to the bottom of the Merkle tree in sequence.

[0128] Step S340: Select the hash values ​​of the leaf nodes in sequence according to the set number to calculate the hash value of the parent node; repeat the following operations until the current baseline Merkle root is obtained: use the calculated parent node hash value as the hash value of the next layer of leaf nodes, calculate the new parent node hash value, until the number of parent node hash values ​​is 1;

[0129] Step S350: Send the current benchmark Merkle root so that the smart contract service platform can compare the current benchmark Merkle root with the current verification Merkle root to verify the consistency of the contract certificate.

[0130] Optionally, values ​​from predefined fields selected from the contract document are concatenated in a fixed order, and a hash value is calculated on the concatenated string. The predefined fields include one or more of the following:

[0131] Contract instance identifier, contract certificate identifier, smart contract operation and management organization identifier, contract instruction execution sequence number, contract wallet identifier, contract wallet operation record, contract storage operation record, oracle operation record.

[0132] Optionally, the current benchmark Merkle root calculated for each contract instance is assembled to obtain and send the benchmark data structure table.

[0133] Optionally, the baseline data structure table may also include the number of contract vouchers.

[0134] Optionally, using the calculated parent node hash value as the hash value of the next-level leaf node, calculate a new parent node hash value, until the number of parent node hash values ​​is 1, specifically including:

[0135] If the number of parent node hash values ​​obtained in the current calculation is 1, then the current base Merkle root is the parent node hash value;

[0136] If the number of parent node hash values ​​obtained by the current calculation is greater than 1, then the calculated parent node hash value is used as the hash value of the next layer of leaf nodes. The new parent node hash value is calculated by selecting the leaf node hash value of the next layer in turn according to the set number, until the number of parent node hash values ​​is 1. The parent node hash value when the number of parent node hash values ​​is 1 is used as the current baseline Merkle root.

[0137] Optionally, if the current verification Merkle root and the current benchmark Merkle root are inconsistent, the system may receive a verification result indicating that the consistency verification has failed, sent by the smart contract service platform.

[0138] Optionally, an updated contract certificate may be sent based on the verification result.

[0139] Figure 4 A flowchart illustrating a contract credential consistency verification method according to at least one embodiment of the present disclosure is shown. Prior to step 200 of the method for verifying contract credential consistency using the Merklegen comparison in the smart contract central management agency 110, a pre-verification can be performed, including:

[0140] Optionally, in step S110, if the current time window is not the first time window, it is determined that the preceding verification Merkle root calculated in the previous time window and the obtained preceding benchmark Merkle root have been verified to be consistent, and the preceding verification Merkle root or the preceding benchmark Merkle root is used as the preceding Merkle root (the two are consistent at this time), that is, it is first confirmed that the contract documents before the current time window have been verified to be consistent.

[0141] Optionally, in step S120, it is determined that the transaction backtracking verification of all contract credentials generated within the previous time window has passed. The transaction backtracking process involves repeatedly executing the smart contract to verify the contract credentials. It is understood that even if the contract credentials are verified to be consistent between the smart contract central management institution 110 and the smart contract operation management institution 120, there is still a possibility that the smart contract operation management institution 120 may arbitrarily or maliciously modify the contract instance, thereby changing the contract execution result. Therefore, the smart contract central management institution 110 can perform transaction backtracking verification by repeatedly executing the smart contract in the local contract execution environment.

[0142] Specifically, after receiving the contract credential data that needs to be verified, the data is parsed. After parsing, the oracle and storage operation records are sorted in ascending order according to their sequential numbers and placed into memory. Using the local environment interface and oracle interface for mock processing, the parsed credential data is retrieved from memory during transaction backtracking, ultimately completing the replay and verification of the transaction.

[0143] Optionally, step S130, verifying the data structure table and the baseline data structure table, also includes the number of contract vouchers (i.e., the number of leaf nodes). Before comparing the current verification Merkle root and the current baseline Merkle root, the number of contract vouchers in the verification data structure table and the baseline data structure table are compared to see if they are consistent. When the number of contract vouchers is consistent, the specific contract voucher information is then verified based on the Merkle root. For example, if the number of contract vouchers in the baseline data structure table provided by the smart contract operation management organization 120 is large, the smart contract operation management organization 120 is required to supplement the contract vouchers through information synchronization messages; if the number of contract vouchers obtained by the smart contract service platform 113 is large, the smart contract operation management organization 120 is notified to process it, specifically, the inconsistent contract vouchers can be determined according to the contract instruction execution sequence number.

[0144] Figure 6 A schematic diagram of the main modules of a contract credential consistency verification device according to at least one embodiment of the present disclosure is shown. The device is applied to a smart contract service platform 113 and includes:

[0145] The platform's sending and receiving module 1131 obtains the contract credentials generated by the smart contract operation and management organization 120 within the current time window;

[0146] The platform hash calculation module 1132 groups the contract vouchers according to their corresponding contract instances, sorts the contract vouchers in each group, and calculates the hash value of each contract voucher.

[0147] The platform's Merkle root generation module 1133 constructs a Merkle tree for each contract instance using a set number of branching tree structures. If the current time window is the first time window, the first leaf node is the hash value of a specific string; if the current time window is not the first time window, the first leaf node is the preorder Merkle root of the contract instance in the previous time window. Starting from the second leaf node, the calculated hash values ​​of contract credentials are sequentially added to the bottom of the Merkle tree. The hash values ​​of leaf nodes are sequentially selected according to a set number to calculate the parent node hash value. The following operations are repeated until the current verification Merkle root is obtained: using the calculated parent node hash value as the hash value of the next layer of leaf nodes, a new parent node hash value is calculated until the number of parent node hash values ​​is 1.

[0148] The platform's sending and receiving module 1131 also obtains the current benchmark Merkle root generated by the smart contract operation and management organization 120 based on the contract certificate for the contract instance and the current time window.

[0149] Platform verification module 1134 compares the current verification Merkle root with the current benchmark Merkle root to verify the consistency of the contract certificate.

[0150] Figure 7 A schematic diagram of the main modules of a contract certificate consistency verification device according to at least one embodiment of the present disclosure is shown. This device is applied to a smart contract operation and management system and includes:

[0151] The contract execution module 1201 executes the contract instance, generates and sends the contract certificate, so that the smart contract service platform 113 can calculate and obtain the current verification Merkle root;

[0152] The institutional hash calculation module 1202 selects contract vouchers generated within the current time window, groups them according to their corresponding contract instances, sorts the contract vouchers in each group, and calculates the hash value of each contract voucher.

[0153] The Merkle root generation module 1203 constructs a Merkle tree for each contract instance using a set number of branching tree structures. If the current time window is the first time window, the first leaf node is the hash value of a specific string; if the current time window is not the first time window, the first leaf node is the preorder Merkle root of the contract instance in the previous time window. Starting from the second leaf node, the calculated hash values ​​of contract credentials are sequentially added to the bottom of the Merkle tree. The hash values ​​of leaf nodes are sequentially selected according to a set number to calculate the hash value of the parent node. The following operations are repeated until the current baseline Merkle root is obtained: using the calculated parent node hash value as the hash value of the next layer of leaf nodes, a new parent node hash value is calculated until the number of parent node hash values ​​is 1.

[0154] The institution's transceiver module 1204 sends the current benchmark Merkle root so that the smart contract service platform 113 can compare the current benchmark Merkle root with the current verification Merkle root to verify the consistency of the contract certificate.

[0155] The embodiments of this disclosure obtain contract credentials generated by the smart contract operation and management organization within the current time window; group the contract credentials according to their corresponding contract instances, sort the contract credentials within each group, and calculate the hash value of each contract credential; for each contract instance, construct a Merkle tree with a set number of branching tree structures and calculate the current verification Merkle root; obtain the current baseline Merkle root sent by the smart contract operation and management organization for that contract instance; and compare the current verification Merkle root and the current baseline Merkle root to verify the consistency of the contract credentials. In other words, the embodiments of this disclosure generate Merkle trees for contract credentials generated by each contract instance within the same time period between the smart contract operation and management organization and the smart contract service platform, and achieve consistency verification of the contract credentials corresponding to each contract instance by comparing the Merkle roots; at the same time, by writing the preceding Merkle root as the first leaf node into the current Merkle tree, the traceability and immutability of historical transactions are ensured, and transaction security is improved.

[0156] It should be noted that the above application scenarios are merely exemplary, intended to describe one or more aspects of this disclosure in specific scenarios. However, these aspects are not essential, and various modifications can be made to the application scenario. It is readily understood that the specific application scenarios described in this disclosure are not limited.

[0157] At least some embodiments of this disclosure also provide an electronic device. Figure 8 A schematic diagram of an electronic device 800 according to at least one embodiment of the present disclosure is shown.

[0158] like Figure 8As shown, the electronic device 800 includes one or more processors 810 and a memory 820. The memory 820 includes one or more computer program modules 821. The one or more computer program modules 821 are stored in the memory 820 and are executed by the processor 810. These computer program modules 821 include instructions for executing a contract credential consistency verification method and its additional aspects according to at least one embodiment of the present disclosure. When executed by the processor 810, they can perform one or more steps of the contract credential consistency verification method and its additional aspects according to at least one embodiment of the present disclosure. The memory 820 and the processor 810 can be interconnected via a bus system and / or other forms of connection mechanisms (not shown). For example, the bus can be a Peripheral Component Interconnect Standard (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus can be divided into an address bus, a data bus, a control bus, etc.

[0159] For example, processor 810 may be a central processing unit (CPU), a digital signal processor (DSP), or other processing unit with data processing and / or program execution capabilities, such as a field-programmable gate array (FPGA). Processor 810 may be a general-purpose processor or a special-purpose processor, capable of controlling other components in electronic device 800 to perform desired functions.

[0160] Exemplarily, memory 820 may include any combination of one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. Volatile memory may include, for example, random access memory (RAM) and / or cache memory. Non-volatile memory may include, for example, read-only memory (ROM), hard disk, erasable programmable read-only memory (EPROM), portable compact disc read-only memory (CD-ROM), USB memory, flash memory, etc. One or more computer program modules 821 may be stored on the computer-readable storage medium, and processor 810 may run one or more computer program modules 821 to implement various functions of electronic device 800. The computer program modules include multiple computer-executable instructions. Various application programs and various data, as well as various data used and / or generated by the application programs, may also be stored in the computer-readable storage medium.

[0161] For example, electronic device 800 may also include input devices such as touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, and gyroscopes; output devices such as liquid crystal displays, speakers, and vibrators; storage devices such as magnetic tapes and hard disks (HDDs or SDDs); and communication devices such as network interface cards like LAN cards and modems. The communication devices allow electronic device 800 to communicate wirelessly or wiredly with other devices to exchange data and perform communication processing via networks such as the Internet. A drive is connected to the I / O interface as needed. Removable storage media, such as disks, optical disks, magneto-optical disks, and semiconductor memories, are installed on the drive as needed so that computer programs read from them can be installed into the storage device as required.

[0162] For example, the electronic device 800 may further include a peripheral interface (not shown in the figure). This peripheral interface can be of various types, such as a USB interface, a Lightning interface, etc. The communication device can communicate wirelessly with networks and other devices, such as the Internet, intranets and / or wireless networks such as cellular telephone networks, wireless local area networks (LANs) and / or metropolitan area networks (MANs). Wireless communication can use any of a variety of communication standards, protocols, and technologies, including but not limited to Global System for Mobile Communications (GSM), Enhanced Data GSM Environment (EDGE), Wideband Code Division Multiple Access (W-CDMA), Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Bluetooth, Wi-Fi (e.g., based on IEEE 802.11a, IEEE 802.11b, IEEE 802.11g, and / or IEEE 802.11n standards), Voice over Internet Protocol (VoIP), Wi-MAX, protocols for email, instant messaging, and / or Short Message Service (SMS), or any other suitable communication protocol.

[0163] The electronic device 800 may be, for example, a system-on-a-chip (SOC) or a device including the SOC. For instance, it can be any device such as a mobile phone, tablet computer, laptop computer, e-reader, game console, television, digital photo frame, navigator, home appliance, communication base station, industrial controller, server, etc., or any combination of data processing devices and hardware. The embodiments of this disclosure do not limit this. The specific functions and technical effects of the electronic device 800 can be found in the description above of the contract certificate consistency verification method and its additional aspects according to at least one embodiment of this disclosure, and will not be repeated here.

[0164] Figure 9 A schematic diagram of a readable storage medium 900 according to at least one embodiment of the present disclosure is shown.

[0165] like Figure 9 As shown, a computer program 910 is stored on a readable storage medium 900, which is a computer-readable storage medium. When the computer program 910 is executed by a processor, it performs one or more steps of the above-described contract certificate consistency verification method and its additional aspects.

[0166] For example, when the program code is read by a computer, the computer can execute the program code stored in the computer storage medium to perform one or more steps to implement, for example, the contract credential consistency verification method and its additional aspects according to at least one embodiment of the present disclosure.

[0167] For example, the readable storage medium may include a memory card of a smartphone, a storage component of a tablet computer, a hard disk of a personal computer, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), portable compact disc read-only memory (CD-ROM), flash memory, and other readable storage media or any combination thereof. The readable storage medium 900 may be a non-transitory readable storage medium.

[0168] At least some of the embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other.

[0169] It should be noted that, in this disclosure, relational terms such as "first," "second," etc., are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0170] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, or they may sometimes be executed in reverse order, depending on the functions involved; that is, the preceding or following operations are not necessarily executed precisely in sequence. Instead, various steps may be processed in reverse order or simultaneously as needed. Furthermore, other operations may be added to these processes, or one or more operations may be removed from these processes.

[0171] The units described in the embodiments of this disclosure can be implemented in software or hardware. The described units can also be located in a processor. The names of these units do not, in some cases, constitute a limitation on the unit itself.

[0172] The following points should be noted regarding this disclosure:

[0173] (1) The accompanying drawings of the embodiments of this disclosure only involve the structures involved in the embodiments of this disclosure. Other structures can be referred to the general design.

[0174] (2) Where there is no conflict, the embodiments of this disclosure and the features in the embodiments can be combined with each other to obtain new embodiments.

[0175] The above are merely exemplary embodiments of this disclosure and are not intended to limit the scope of protection of this disclosure, which is determined by the appended claims.

Claims

1. A method for verifying the consistency of contract documents, characterized in that, The method, applied to a smart contract service platform, includes: Obtain the contract credentials generated by the smart contract operation and management system within the current time window; The contract credentials are grouped according to their corresponding contract instances, the contract credentials within each group are sorted, and the hash value of each contract credential is calculated. For each contract instance, a Merkle tree is constructed using a set number of branching tree structures. If the current time window is the first time window, the first leaf node is the hash value of a specific string. If the current time window is not the first time window, the first leaf node is the preorder Merkle root of the contract instance in the previous time window. Starting from the second leaf node, the calculated hash values ​​of the contract credentials are sequentially added to the bottom of the Merkle tree. Select the hash values ​​of the leaf nodes sequentially according to the set number to calculate the hash value of the parent node; repeat the following operations until the current verification Merkle root is obtained: use the calculated parent node hash value as the hash value of the next layer of leaf nodes, calculate the new parent node hash value, until the number of parent node hash values ​​is 1; Obtain the current baseline Merkle root generated from the contract credentials for this contract instance based on the current time window sent by the smart contract operation and management organization system; The current verification Merkle root and the current benchmark Merkle root are compared to verify the consistency of the contract credentials.

2. The method of claim 1, wherein, Before calculating the hash value of each contract credential, the method further includes: The values ​​of predefined fields selected from the contract certificate are concatenated in a fixed order, and the hash value of the concatenated string is calculated. The predefined fields include one or more of the following: Contract instance identifier, contract certificate identifier, smart contract operation and management organization identifier, execution sequence number of the contract instructions, contract wallet identifier, contract wallet operation record, contract storage operation record, oracle operation record.

3. The method of claim 1, wherein, The method further includes: assembling the current verification Merkle root obtained from each contract instance to obtain a verification data structure table; The step of obtaining the current benchmark Merkle root sent by the smart contract operation and management organization system includes: obtaining the benchmark data structure table generated based on the current benchmark Merkle root sent by the smart contract operation and management organization system; The step of comparing the current verification Merkle root and the current benchmark Merkle root to verify the consistency of the contract certificate includes: comparing the verification data structure table and the benchmark data structure table to obtain the comparison result of the current verification Merkle root and the current benchmark Merkle root, thereby verifying the consistency of the contract certificate.

4. The method of claim 3, wherein, The comparison of the verification data structure table and the benchmark data structure table includes: assembling both the verification data structure table and the benchmark data structure table in sequence according to the contract instance identifier, and calculating the hash values ​​of the verification data structure table and the benchmark data structure table respectively to compare the consistency of the data between the two.

5. The method of claim 3, wherein, The verification data structure table and the benchmark data structure table also include the number of contract vouchers; Before comparing the current verification Merkle root with the current benchmark Merkle root, the method further includes: Compare the number of contract vouchers in the verification data structure table and the benchmark data structure table to see if they are consistent.

6. The method of claim 1, wherein, The method further includes: If the current time window is not the first time window, it is determined that the preceding verification Merkle root obtained from the previous time window and the obtained preceding benchmark Merkle root have been verified to be consistent, and the preceding verification Merkle root or the preceding benchmark Merkle root is taken as the preceding Merkle root.

7. The method of claim 6, wherein, The method also includes: determining that the transaction backtracking verification of each contract certificate generated within the previous time window has passed.

8. The method of claim 1, wherein, The step of using the calculated parent node hash value as the next level leaf node hash value, calculating a new parent node hash value, until the number of parent node hash values ​​is 1, includes: If the number of parent node hash values ​​obtained in the current calculation is 1, then the current verification Merkle root is set to that parent node hash value. If the number of parent node hash values ​​obtained by the current calculation is greater than 1, then the calculated parent node hash value is used as the hash value of the next layer of leaf nodes. The new parent node hash value is calculated by sequentially selecting the leaf node hash value of the next layer according to the set number, until the number of parent node hash values ​​is 1. The parent node hash value when the number of parent node hash values ​​is 1 is used as the current verification Merkle root.

9. The method of claim 1, wherein, If the current verification Merkle root and the current benchmark Merkle root are inconsistent, a verification result indicating a consistency verification failure is sent to the smart contract operation and management system.

10. The method according to claim 9, characterized in that, The method further includes: Receive the updated contract certificate sent by the smart contract operation and management system based on the verification result, obtain the Merkel path and recalculate the hash value of the contract certificate, replace the original leaf node's hash value based on the recalculated hash value, and calculate a new current verification Merkel root according to the Merkel path; The new current verification Merkle root is compared with the current benchmark Merkle root to verify the consistency of the contract credentials.

11. A method for verifying the consistency of contract credentials, characterized by, The method, applied to a smart contract operation and management system, includes: Execute the contract instance, generate and send the contract credentials so that the smart contract service platform can calculate and obtain the current verification Merkle root; Select contract credentials generated within the current time window, group them according to their corresponding contract instances, sort the contract credentials within each group, and calculate the hash value of each contract credential. For each contract instance, a Merkle tree is constructed using a set number of branching tree structures. If the current time window is the first time window, the first leaf node is the hash value of a specific string. If the current time window is not the first time window, the first leaf node is the preorder Merkle root of the contract instance in the previous time window. Starting from the second leaf node, the calculated hash values ​​of the contract credentials are sequentially added to the bottom of the Merkle tree. Select the hash values ​​of the leaf nodes sequentially according to the set number to calculate the hash value of the parent node; repeat the following operations until the current baseline Merkle root is obtained: use the calculated parent node hash value as the hash value of the next layer of leaf nodes, calculate the new parent node hash value, until the number of parent node hash values ​​is 1; The current benchmark Merkle root is sent so that the smart contract service platform can compare the current benchmark Merkle root with the current verification Merkle root to verify the consistency of the contract certificate.

12. The method of claim 11, wherein, Before calculating the hash value of each contract credential, the method further includes: The values ​​of predefined fields selected from the contract certificate are concatenated in a fixed order, and the hash value of the concatenated string is calculated. The predefined fields include one or more of the following: Contract instance identifier, contract certificate identifier, smart contract operation and management organization identifier, execution sequence number of the contract instructions, contract wallet identifier, contract wallet operation record, contract storage operation record, oracle operation record.

13. The method of claim 11, wherein, Assemble the current benchmark Merkle root obtained from the calculation of each contract instance, and obtain and send the benchmark data structure table.

14. The method of claim 13, wherein, The baseline data structure table also includes the number of contract vouchers.

15. The method of claim 11, wherein, The step of using the calculated parent node hash value as the next level leaf node hash value, calculating a new parent node hash value, until the number of parent node hash values ​​is 1, includes: If the number of parent node hash values ​​obtained in the current calculation is 1, then the current baseline Merkle root is used as the parent node hash value; If the number of parent node hash values ​​obtained by the current calculation is greater than 1, then the calculated parent node hash value is used as the hash value of the next layer of leaf nodes. The new parent node hash value is calculated by sequentially selecting the leaf node hash value of the next layer according to the set number, until the number of parent node hash values ​​is 1. The parent node hash value when the number of parent node hash values ​​is 1 is used as the current benchmark Merkle root.

16. The method of claim 11, wherein, If the current verification Merkle root and the current benchmark Merkle root are inconsistent, the system receives a consistency verification failure result sent by the smart contract service platform.

17. The method of claim 16, wherein, The method further includes sending an updated contract certificate based on the verification result.

18. A contract document consistency verification apparatus characterized by comprising: The device, used in a smart contract service platform, includes: The platform's sending and receiving module is configured to obtain contract credentials generated by the smart contract operation and management system within the current time window; The platform hash calculation module is configured to group the contract credentials according to their corresponding contract instances, sort the contract credentials within each group, and calculate the hash value of each contract credential. The platform's Merkle root generation module is configured to construct a Merkle tree for each contract instance using a set number of branching tree structures. If the current time window is the first time window, the first leaf node is the hash value of a specific string; if the current time window is not the first time window, the first leaf node is the preorder Merkle root of the contract instance in the previous time window. Starting from the second leaf node, the calculated hash values ​​of the contract credentials are sequentially added to the bottom of the Merkle tree. The hash values ​​of the leaf nodes are sequentially selected according to the set number to calculate the parent node hash value. The following operations are repeated until the current verification Merkle root is obtained: using the calculated parent node hash value as the hash value of the next layer of leaf nodes, a new parent node hash value is calculated until the number of parent node hash values ​​is 1. The platform's transceiver module is also configured to obtain the current baseline Merkle root generated by the contract certificate based on the current time window for the contract instance sent by the smart contract operation and management agency system. The platform verification module is configured to compare the current verification Merkle root with the current benchmark Merkle root to verify the consistency of the contract certificate.

19. A contract document consistency verification apparatus characterized by comprising: The device, used in a smart contract operation and management system, includes: The contract execution module is configured to execute contract instances, generate and send contract credentials so that the smart contract service platform can calculate and obtain the current verification Merkle root; The institutional hash calculation module is configured to select contract credentials generated within the current time window, group them according to their corresponding contract instances, sort the contract credentials within each group, and calculate the hash value of each contract credential. The Merkle root generation module is configured to construct a Merkle tree for each contract instance using a set number of branching tree structures. If the current time window is the first time window, the first leaf node is the hash value of a specific string; if the current time window is not the first time window, the first leaf node is the preorder Merkle root of the contract instance in the previous time window. Starting from the second leaf node, the calculated hash values ​​of the contract credentials are sequentially added to the bottom of the Merkle tree. The hash values ​​of the leaf nodes are sequentially selected according to the set number to calculate the parent node hash value. The following operations are repeated until the current baseline Merkle root is obtained: using the calculated parent node hash value as the hash value of the next layer of leaf nodes, a new parent node hash value is calculated until the number of parent node hash values ​​is 1. The institution's sending and receiving module is configured to send the current benchmark Merkle root so that the smart contract service platform can compare the current benchmark Merkle root with the current verification Merkle root to verify the consistency of the contract certificate.

20. An electronic device, comprising: include: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-17.

21. A computer readable medium having stored thereon a computer program, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-17.

Images