Smart contract whitelist verification method, device, electronic device and storage medium

Abstract

The present application provides a whitelist verification method, device, electronic device and storage medium for smart contracts. The method includes: obtaining a public key whitelist to obtain a public key list, sorting the elements in the public key list, and processing the public key list to obtain an ordered public key list; performing a hash operation on each pair of public keys in the ordered public key list to generate a hash value, recursively performing a combined hash operation on the hash value generated in the previous layer until a root hash value is obtained; determining the sibling nodes and parent nodes of the public key in the binary tree, and recursively determining the sibling nodes in each level to construct a verification path; performing a hash operation on the public key, and using the verification path to calculate the combined hash value step by step until the final hash value is obtained, and comparing the final hash value with the root hash value; passing the verification path as a parameter and calling the verification method. The present application reduces centralized trust costs and read and write costs, and improves the security and transparency of the system.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a whitelist verification method, device, electronic device, and storage medium for smart contracts. Background Art

[0002] With the development of blockchain technology, smart contracts have gained widespread application in fields such as finance and supply chain management. By automatically executing pre-defined contract terms, smart contracts ensure transparent and tamper-proof transactions. In these application scenarios, it is often necessary to restrict the execution of certain business logic to specific users, necessitating a whitelist mechanism to control user permissions.

[0003] Currently, there are two main ways to implement the whitelist mechanism in smart contracts:

[0004] The first method uses a centralized database off-chain:

[0005] In this approach, whitelist information is stored in a centralized off-chain database. When a user attempts to execute a smart contract, the system queries this database to verify whether the user is on the whitelist. Centralized databases pose the risk of replay attacks, where attackers can capture and resend legitimate requests, causing the system to repeat operations. The use of a centralized database reduces transparency because whitelist data is not publicly available on the blockchain and relies on a single trusted entity, increasing the cost of trust.

[0006] The second method uses the mapping storage structure of the smart contract:

[0007] In this approach, whitelist information is stored directly in the smart contract's mapping structure. When a user executes the smart contract, the smart contract reads the mapping structure to verify user permissions. The mapping structure is expensive to store and read / write, especially when the whitelist size is large. This leads to high blockchain resource consumption and transaction fees. Summary of the Invention

[0008] In view of this, the embodiments of the present application provide a whitelist verification method, device, electronic device and storage medium for a smart contract to solve the problems of high centralized trust cost and read-write cost, and low system security and transparency in the existing technology.

[0009] In a first aspect of an embodiment of the present application, a whitelist verification method for a smart contract is provided, comprising: obtaining a public key whitelist to obtain a public key list; sorting the elements in the public key list and processing the public key list according to the number of elements in the public key list to obtain an ordered public key list; performing a hash operation on each pair of public keys in the ordered public key list to generate a corresponding hash value, recursively performing a combined hash operation on the hash values ​​generated in the previous layer until a root hash value is obtained, and storing the root hash value in the state of the smart contract; determining the sibling nodes and parent nodes of the public key in a binary tree, and recursively determining the sibling nodes in each layer to construct a verification path; performing a hash operation on the public key and calculating the combined hash value level by level using the verification path until a final hash value is obtained, comparing the final hash value with the root hash value, and if they are equal, verification passes, otherwise verification fails; in response to a user calling an operation of the smart contract, obtaining a verification path corresponding to the user's public key, passing the verification path as a parameter, and calling the verification method before a business method that requires whitelist verification, and continuing to execute the business logic if the verification passes, otherwise terminating the execution.

[0010] According to a second aspect of the embodiment of the present application, a whitelist verification device for a smart contract is provided, comprising: an acquisition module configured to acquire a public key whitelist to obtain a public key list; a processing module configured to sort the elements in the public key list and process the public key list according to the number of elements in the public key list to obtain an ordered public key list; an operation module configured to perform a hash operation on each pair of public keys in the ordered public key list to generate a corresponding hash value, and recursively perform a combined hash operation on the hash values ​​generated in the previous layer until a root hash value is obtained, and the root hash value is stored in the state of the smart contract; a construction module configured to determine the public key list. The key is in the sibling node and parent node of the binary tree, and the sibling nodes in each level are recursively determined to construct a verification path; the comparison module is configured to perform a hash operation on the public key, and use the verification path to calculate the combined hash value step by step until the final hash value is obtained, and the final hash value is compared with the root hash value. If they are equal, the verification passes, otherwise the verification fails; the verification module is configured to respond to the user's call to the smart contract operation, obtain the user's corresponding public key verification path, and pass the verification path as a parameter, and call the verification method before the business method that needs to verify the whitelist. If the verification passes, the business logic continues to execute, otherwise the execution is terminated.

[0011] According to a third aspect of an embodiment of the present application, an electronic device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the steps of the above method are implemented when the processor executes the computer program.

[0012] According to a fourth aspect of the embodiments of the present application, a computer-readable storage medium is provided, which stores a computer program. When the computer program is executed by a processor, the steps of the above method are implemented.

[0013] At least one of the above technical solutions adopted in the embodiments of the present application can achieve the following beneficial effects:

[0014] The public key list is obtained by obtaining a public key whitelist; the elements in the public key list are sorted, and the public key list is processed according to the number of elements in the public key list to obtain an ordered public key list; each pair of public keys in the ordered public key list is hashed to generate a corresponding hash value, and the hash value generated in the previous layer is recursively combined with the hash value until the root hash value is obtained, and the root hash value is stored in the state of the smart contract; the sibling nodes and parent nodes of the public key in the binary tree are determined, and the sibling nodes in each level are recursively determined to construct a verification path; the public key is hashed and the combined hash value is calculated step by step using the verification path until the final hash value is obtained, and the final hash value is compared with the root hash value. If they are equal, the verification passes, otherwise the verification fails; in response to the user calling the smart contract operation, the verification path of the user's corresponding public key is obtained, and the verification path is passed as a parameter. The verification method is called before the business method that needs to verify the whitelist. If the verification passes, the business logic continues to execute, otherwise the execution is terminated. This application reduces the centralized trust cost and read and write cost, and improves the security and transparency of the system. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0016] Figure 1 This is a flowchart of the whitelist verification method for smart contracts provided in an embodiment of the present application;

[0017] Figure 2 This is a schematic diagram of the construction process of a binary tree in an actual scenario provided by an embodiment of the present application;

[0018] Figure 3 This is a schematic diagram of the process of constructing a verification path in an actual scenario provided by an embodiment of the present application;

[0019] Figure 4 This is a schematic diagram of the structure of the whitelist verification device for the smart contract provided in an embodiment of the present application;

[0020] Figure 5It is a structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0021] In the following description, specific details such as specific system structures and techniques are provided for purposes of illustration rather than limitation to facilitate a thorough understanding of the embodiments of the present application. However, it will be apparent to those skilled in the art that the present application may be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to avoid obscuring the description of the present application with unnecessary detail.

[0022] Smart contracts are programs deployed on the blockchain that automatically execute contract terms and ensure transaction transparency and immutability. Smart contracts are widely used in fields such as finance and supply chain management. In these applications, it's often necessary to restrict specific users from executing certain business logic, necessitating the use of a whitelist mechanism to limit the user scope.

[0023] Currently, there are two main ways to implement the whitelist mechanism in smart contracts:

[0024] The first method uses a centralized database off-chain:

[0025] In this approach, whitelist information is stored in a centralized database off-chain. When a user attempts to execute a smart contract, the system queries the centralized database to verify whether the user is on the whitelist.

[0026] The first method has the following disadvantages:

[0027] There is a risk of replay attacks, where an attacker can capture and repeatedly send legitimate requests, causing the system to perform repeated operations.

[0028] The use of a centralized database reduces the transparency of the entire system because whitelist data is not publicly available on the blockchain.

[0029] The second method uses the mapping storage structure of the smart contract:

[0030] This method stores the whitelist information directly in the mapping structure of the smart contract.

[0031] Whenever a user executes a smart contract, the smart contract reads the mapping structure to verify the user's permissions.

[0032] The second method has the following disadvantages:

[0033] The reading and writing costs of the mapping structure are high, especially when the whitelist size is large, which will lead to a large amount of blockchain resource consumption and high transaction fees.

[0034] Therefore, the existing whitelist mechanism has the following technical problems:

[0035] 1. High centralized trust cost: The whitelist mechanism using a centralized database relies on a single trusted entity, which increases the trust cost and security risks of the system.

[0036] 2. Lack of transparency: The whitelist data in the centralized database is not public, which reduces the transparency and credibility of the system.

[0037] 3. High storage cost: Using the mapping storage structure of smart contracts will result in high read and write costs, especially when the whitelist size is large, which will increase the consumption of blockchain resources and transaction fees.

[0038] In view of the above-mentioned deficiencies in the existing technology, this application proposes a whitelist verification method that combines on-chain and off-chain, aiming to reduce the centralized trust cost and the high read and write cost of the mapping storage structure, while improving the security and transparency of the system.

[0039] The contents of the technical solution of this application are described in detail below with reference to the accompanying drawings and specific embodiments.

[0040] Figure 1 This is a flowchart of the whitelist verification method for smart contracts provided in an embodiment of the present application. Figure 1 The whitelist verification method of the smart contract can be executed by the application. Figure 1 As shown, the whitelist verification method of the smart contract may specifically include:

[0041] S101, obtaining a public key whitelist to obtain a public key list;

[0042] S102, sorting the elements in the public key list, and processing the public key list according to the number of elements in the public key list to obtain an ordered public key list;

[0043] S103, performing a hash operation on each pair of public keys in the ordered public key list to generate a corresponding hash value, recursively performing a combined hash operation on the hash values ​​generated in the previous layer until a root hash value is obtained, and storing the root hash value in the state of the smart contract;

[0044] S104, determining the sibling nodes and parent nodes of the public key in the binary tree, and recursively determining the sibling nodes in each level to construct a verification path;

[0045] S105, performing a hash operation on the public key and calculating the combined hash value step by step using the verification path until a final hash value is obtained. The final hash value is compared with the root hash value. If they are equal, the verification passes; otherwise, the verification fails.

[0046] S106, in response to the user calling the smart contract operation, obtain the verification path of the user's corresponding public key, and pass the verification path as a parameter, and call the verification method before the business method that needs to verify the whitelist. If the verification passes, continue to execute the business logic, otherwise terminate the execution.

[0047] In some embodiments, obtaining a public key whitelist to obtain a public key list includes:

[0048] Use the elliptic curve algorithm to generate public and private key pairs, and set the public and private key pairs to be visible to the business. According to the business requirements provided by the business party, organize and generate a public key whitelist to obtain a public key list.

[0049] Specifically, users use an elliptic curve algorithm to generate a public-private key pair. In practice, elliptic curve algorithms (such as SECP256k1) are commonly used public-key encryption algorithms with high security and efficiency. The user-generated public key is 256 bits long and is made visible to the business, allowing subsequent business operations to be verified using the public key.

[0050] Furthermore, based on the business requirements provided by the business party, a public key whitelist is compiled and generated. Based on the needs of the actual business scenario, the business party will collect the public keys of users authorized to execute smart contracts and form a public key list S. This list S contains the public keys of all authorized users.

[0051] Furthermore, the business side organizes all collected public keys into a public key list S. This list S contains the public keys of all authorized users. For example, the organized public key list S is as follows: [Public Key 1, Public Key 2, Public Key 3]

[0052] Through the method described above, this embodiment discloses how to use an elliptic curve algorithm to generate a public-private key pair, set the generated public key as business-visible, and compile a public key whitelist based on business needs. This process ensures that the smart contract whitelist verification method can effectively control user permissions and achieve secure and efficient access management.

[0053] In some embodiments, the elements in the public key list are sorted, and the public key list is processed according to the number of elements in the public key list to obtain an ordered public key list, including:

[0054] Arrange the elements in the public key list in ascending order and determine the number of elements in the public key list. When the number of elements in the public key list is an odd number, copy the last element in the public key list to the public key list so that the length of the public key list is an even number, thereby obtaining an ordered public key list, wherein the length of the ordered public key list is an even number.

[0055] Specifically, the business party compiles a public key whitelist according to business needs to obtain a public key list S. For example, in a specific example, it is assumed that the public key list S contains the following public keys:

[0056] Public key 1: 04bfcab98d765ec1acb23dc3a23...

[0057] Public key 2: 048f97d7c82b7a1dfda12b1d4f8...

[0058] Public key 3: 04a6b8d7c83c7a5eda24b3c9d3e...

[0059] Furthermore, the elements in the public key list S are sorted in ascending order. Assume that the public key list after ascending order is:

[0060] Public key 2: 048f97d7c82b7a1dfda12b1d4f8...

[0061] Public key 3: 04a6b8d7c83c7a5eda24b3c9d3e...

[0062] Public key 1: 04bfcab98d765ec1acb23dc3a23...

[0063] Next, determine the number of elements in the public key list S. If the number of elements is odd, copy the last element in the public key list S to the list to make the length of the public key list even. Since the current length of list S is 3 (an odd number), copy the last element (public key 1) to the list to obtain the ordered public key list L:

[0064] Public key 2: 048f97d7c82b7a1dfda12b1d4f8...

[0065] Public key 3: 04a6b8d7c83c7a5eda24b3c9d3e...

[0066] Public key 1: 04bfcab98d765ec1acb23dc3a23...

[0067] Public key 1: 04bfcab98d765ec1acb23dc3a23...

[0068] At this point, the length of list L is 4 (an even number). The height H of a binary tree (such as a Merkle tree) can be further calculated using the formula H = log2(N), where N is the length of the ordered public key list L. In this embodiment, N = 4, so H = log2(4) = 2.

[0069] Through the above-described method of this embodiment, this embodiment discloses how to sort a public key list and adjust the list length based on the number of elements to obtain an ordered public key list. This process ensures that the length of the public key list is an even number, laying the foundation for the subsequent construction of the Merkle tree and implementing a whitelist verification method for smart contracts.

[0070] In some embodiments, performing a hash operation on each pair of public keys in the ordered public key list to generate a corresponding hash value, and recursively performing a combined hash operation on the hash values ​​generated in the previous layer until a root hash value is obtained, including:

[0071] Traverse the ordered public key list, perform hash operations on each pair of adjacent public keys in turn according to the preset step size, obtain the hash value of each pair of public keys, and store the hash value in the hash value list; perform a combined hash operation on each pair of hash values ​​in the hash value list to generate a new hash value list, and recursively perform a combined hash operation on each pair of hash values ​​in the new hash value list until the length of the generated new hash value list is 1, and then obtain the root hash value.

[0072] Specifically, the ordered public key list L is traversed, and hash operations are performed on each pair of adjacent public keys in sequence, at a preset step size (e.g., a step size of 2), to generate a hash value for each pair of public keys. The generated hash values ​​are stored in the first-level hash value list. For example, for each pair of public keys in list L, their hash values ​​are calculated and a corresponding hash value list is generated.

[0073] Furthermore, a combined hash operation is performed on each pair of hash values ​​in the first-level hash value list to generate a new hash value list. Specifically, a combined hash operation is performed on the i-th and i+1-th hash values ​​in the first-level hash value list to obtain a new hash value (hash(i,i+1)), which is stored in the new hash value list.

[0074] Furthermore, the above steps are repeated to perform a recursive combined hash operation on each pair of hash values ​​in the new hash value list. After each recursive operation, the generated hash value is stored in the updated hash value list, and the combined hash operation is continued on the updated hash value list until the length of the hash value list is 1.

[0075] Furthermore, when the length of the hash value list is 1, the last hash value is the root hash value. This root hash value is stored in the state of the smart contract for subsequent verification and validation.

[0076] Through the method described above, this embodiment discloses how to perform initial hash calculations, combined hash calculations, and recursive calculations on an ordered list of public keys until a root hash value is generated. This process, by constructing a Merkle tree, enables efficient management and verification of public key lists, providing a foundational guarantee for whitelist verification in smart contracts.

[0077] The following describes in detail the construction process of a binary tree (such as a Merkle tree) with reference to the accompanying drawings and specific embodiments. Figure 2 This is a schematic diagram of the construction process of a binary tree in an actual scenario provided by an embodiment of the present application. Figure 2 As shown, the process of constructing a binary tree in the embodiment of the present application may include the following:

[0078] A Merkle tree is a tree-like data structure in which each leaf node stores the hash value of the original data, and non-leaf nodes store the combined hash value of their child nodes. Ultimately, the root node (root) of the tree stores the root hash value of the entire tree. List Sh is the collection of hash values ​​of nodes at each level during the construction of the Merkle tree.

[0079] Initial state of Sh: In the process of constructing the Merkle tree, first perform a hash operation on each pair of public keys in the ordered public key list L and store the results in the list Sh. At this time, Sh stores the hash values ​​of the leaf nodes of the Merkle tree.

[0080] Recursive generation of Sh: Next, a new list Sh is generated by recursively performing a combined hash operation on each pair of hash values ​​in Sh. Each new layer of Sh represents the hash value of the node in the upper layer in the Merkle tree until the root hash value is generated.

[0081] Hierarchical representation of Sh: Sh can be represented as Sh0, Sh1, Sh2, ..., up to S0, where Sh0 is the hash value of the leaf node and S0 is the root hash value.

[0082] For example, in a specific example, the construction process of the Merkle tree is as follows:

[0083] First, the initial public key hash:

[0084] List L: ordered list of public keys.

[0085] List Sh: Hash each pair of public keys in L and store the result, i.e. Sh0.

[0086] Then, recursively hash:

[0087] List Sh1: Perform a combined hash operation on each pair of hash values ​​in Sh0 to obtain Sh1.

[0088] List Sh2: Perform a combined hash operation on each pair of hash values ​​in Sh1 to obtain Sh2.

[0089] And so on until the root hash value (S0) is obtained.

[0090] Finally, the root hash value is stored in S0, which is the root node of the Merkle tree.

[0091] List Sh is the collection of hash values ​​for each node layer during the Merkle tree construction process. An initial hash calculation is performed on the public key list L to obtain the leaf node hash value list Sh0. Then, the hash value lists for each layer (Sh1, Sh2, ...) are recursively calculated to ultimately obtain the root hash value (S0) of the Merkle tree. This ensures data integrity and verification efficiency.

[0092] In some embodiments, determining sibling nodes and parent nodes of a public key in a binary tree, and recursively determining sibling nodes in each level to construct a verification path, includes:

[0093] Traverse the hash value list of nodes at each layer of the binary tree to determine the current traversal index and the sibling node index of the current node in the current layer;

[0094] Determine the parent node index of the current node in the previous layer, and determine the sibling node index of the parent node in its layer;

[0095] Add the hash values ​​of the sibling nodes of the current layer and the hash values ​​of the sibling nodes of the parent node of the previous layer to the verification path array in sequence, and recursively reach the binary tree layer corresponding to the root hash value to construct a complete verification path array.

[0096] Specifically, the process of constructing the verification path is described in detail below with reference to the accompanying drawings and specific embodiments. Figure 3 This is a schematic diagram of the construction process of the verification path in the actual scenario provided by the embodiment of the present application, such as Figure 3 As shown, the process of constructing a verification path in the embodiment of the present application may include the following:

[0097] Traverse the hash value list Sh of each layer of the binary tree, the current traversal index is i. Assume that Sh represents the hash value list of the current layer.

[0098] Furthermore, the sibling node index of the current node is determined: Based on the currently traversed index i, the sibling node index b of the current node in the current layer is calculated using the formula b = i + 1 - 2 * (i % 2). This formula can be used to determine the sibling node index of the current node and thus obtain the hash value of the sibling node.

[0099] Furthermore, the parent node index is determined by calculating the parent node index p of the current node in the previous layer using the formula p = i / / 2. This formula can be used to determine the parent node index of the current node in the previous layer, thereby obtaining the hash value of the parent node.

[0100] Furthermore, the sibling node index of the parent node is determined: the sibling node index Pb of the parent node in its layer is calculated using the formula Pb = p + 1 - 2 * (p % 2). This formula can be used to determine the sibling node index of the parent node, thereby obtaining the hash value of the parent node's sibling node.

[0101] Furthermore, a verification path array is constructed: the hash value Sh[b] of the sibling node of the current layer and the hash value Sh-1[Pb] of the sibling node of the parent node of the previous layer are added to the verification path array proof in sequence.

[0102] Recursively execute the above steps and perform index calculation on the nodes in each layer in turn until the binary tree layer corresponding to the root hash value is reached.

[0103] Furthermore, a complete verification path is generated:

[0104] Through recursive calculation, the complete verification path array proof is finally obtained, which contains all necessary hash values ​​from the current node to the root hash value. The verification path array proof is used in the subsequent verification process to ensure that the validity of the public key can be correctly verified.

[0105] For example, in one example, assuming that the current traversal index in a certain level Sh list of a binary tree is i, the specific steps are as follows:

[0106] Calculate the sibling node index of the current node b = i + 1 - 2 * (i% 2);

[0107] Calculate the parent node index of the current node in the previous layer p = i / / 2;

[0108] Calculate the sibling node index Pb of the parent node in its layer = p + 1 - 2 * (p% 2);

[0109] Add Sh[b] and Sh-1[Pb] to the verification path array proof;

[0110] Recursively execute the above steps until the binary tree layer corresponding to the root hash value is reached, and finally a complete verification path array proof is generated.

[0111] Through the above-described method of this embodiment, this embodiment discloses how to traverse the hash value list of nodes at each level of the binary tree, determine the sibling nodes and parent nodes of the public key at each level, and recursively construct a verification path. This process ensures that the validity of the public key can be effectively verified, realizing the whitelist verification function of the smart contract.

[0112] In some embodiments, a hash operation is performed on the public key, and a combined hash value is calculated step by step using a verification path until a final hash value is obtained. The final hash value is compared with the root hash value. If they are equal, verification passes; otherwise, verification fails, including:

[0113] Define a verification method in the smart contract, where the return value of the verification method is a Boolean type;

[0114] The caller's public key is used as the input parameter of the verification method, and the hash value of the public key is calculated to obtain the initial hash value;

[0115] Perform a combined hash operation on the initial hash value and the first hash value in the verification path to obtain a first combined hash value;

[0116] Recursively perform a combined hash operation on the generated first combined hash value and the next hash value in the verification path until all hash values ​​in the verification path are used to obtain a final hash value;

[0117] Compare the final hash value with the root hash value stored in the smart contract state. If they are equal, verification passes and returns true; if they are not equal, verification fails and returns false.

[0118] Specifically, a verification method (verify method) is defined in the smart contract, and the return value of this method is a Boolean type. This verification method is used to receive the caller's public key and calculate its hash value. It then performs recursive calculations through the verification path to ultimately verify whether the public key is in the whitelist.

[0119] Furthermore, the public key is received and the initial hash value is calculated: the verification method receives the caller's public key (pub) as an input parameter and calculates the hash value of the public key to obtain the initial hash value (h).

[0120] Furthermore, a combined hash operation is performed: the initial hash value is combined with the first hash value in the verification path (proof[0]) to obtain a first combined hash value. The first combined hash value generated is recursively combined with the next hash value in the verification path.

[0121] Furthermore, the final hash value is recursively calculated: Following the above steps, each combined hash value is recursively calculated with the next hash value in the verification path until all hash values ​​in the verification path are used. The final hash value generated is the final hash value (finalhash).

[0122] Furthermore, the final hash value is compared with the root hash value: the final hash value is compared with the root hash value (root) stored in the smart contract state. If the final hash value and the root hash value are equal, the verification passes and true is returned; if they are not equal, the verification fails and false is returned.

[0123] For example, in one example, the implementation of the verify method defined in the smart contract is as follows:

[0124] The verify method (verify) receives the caller's public key (pub) as a parameter and calculates the hash value (h) of the public key.

[0125] Perform a combined hash operation on h and the first hash value (proof[0]) in the verification path (proof) to obtain the combined hash value h(pub,proof[0]).

[0126] Recursively calculate h(h(pub,proof[0]),proof[1]), performing combined hash operations in sequence until all hash values ​​in the verification path are used up.

[0127] The final generated hash value (finalhash) is compared with the root hash value (root), and true is returned if they are equal, otherwise false is returned.

[0128] Through the above-mentioned method of this embodiment, this embodiment discloses how to define a verification method in a smart contract, perform a hash operation on the public key, and use the verification path to calculate the combined hash value step by step to finally verify the validity of the public key, thereby realizing the whitelist verification function of the smart contract.

[0129] In some embodiments, in response to a user invoking a smart contract operation, a verification path of the user's corresponding public key is obtained, and the verification path is passed as a parameter. A verification method is called before a business method that requires whitelist verification. If the verification passes, the business logic continues to execute, otherwise the execution is terminated, including:

[0130] When a user calls a smart contract, a request is sent to the server, the user's public key is used to obtain the corresponding verification path, and the obtained verification path is passed as a parameter to the smart contract;

[0131] Use smart contracts to call the verification method before each business method that requires whitelist verification, so as to verify based on the user's public key and verification path;

[0132] The user's public key is hashed using the verification method, and the combined hash values ​​are calculated step by step through the verification path until the final hash value is obtained. The final hash value is compared with the root hash value stored in the smart contract state;

[0133] If the final hash value is equal to the root hash value, the verification is passed and the smart contract continues to execute the business logic. If the final hash value is not equal to the root hash value, the verification fails and the smart contract terminates execution.

[0134] Specifically, when a user calls a smart contract, they first send a request to the server and use their public key to obtain the corresponding verification path (proof). The server generates the corresponding verification path from the whitelist based on the user's public key and returns the verification path to the user.

[0135] Furthermore, when a user calls a smart contract, they pass the obtained proof as a parameter to the smart contract. For example, when a user calls a smart contract method, they include the proof in the parameter so that the smart contract can obtain the proof for verification.

[0136] Furthermore, the smart contract calls a verification method (verify method) before each business method that requires whitelist verification to perform verification based on the user's public key and verification path. The verification method receives the user's public key and verification path as input parameters and performs hash calculation and verification.

[0137] Furthermore, the verification method hashes the user's public key to generate an initial hash value. This initial hash value is hashed together with the first hash value in the verification path to produce a combined hash value. This combined hash value is recursively hashed together with the next hash value in the verification path until all hash values ​​in the verification path have been used, resulting in a final hash value. This final hash value is then compared with the root hash value stored in the smart contract state.

[0138] Furthermore, if the final hash value is equal to the root hash value, the verification is passed, true is returned, and the smart contract continues to execute the business logic. If the final hash value is not equal to the root hash value, the verification fails, false is returned, and the smart contract terminates execution.

[0139] For example, in one example, the implementation of the verification method (verify) in the smart contract is as follows:

[0140] When a user calls a contract, he first requests the server to obtain a verification path (proof) using his public key.

[0141] When a user calls a smart contract, the verification path (proof) is passed into the smart contract as a parameter.

[0142] The contract calls the verification method (verify) before each business method that needs to verify the whitelist.

[0143] The verify method receives the caller's public key (pub) as a parameter, calculates its hash value (h), and then combines h with the first hash value in the verification path (proof[0]) to calculate the hash value to obtain the combined hash value.

[0144] The combined hash value is recursively calculated until all hash values ​​in the verification path are used up to obtain the final hash value (finalhash).

[0145] Compare the final hash value with the root hash value (root). If they are equal, return true and continue executing the business logic; if they are not equal, return false and terminate the execution of the business logic.

[0146] Through the above-mentioned method of this embodiment, this embodiment discloses how to respond to the user's call to the smart contract operation, obtain the verification path and perform verification, ensure that only verified users can execute the business logic in the smart contract, and realize the whitelist verification function of the smart contract.

[0147] According to the technical solution provided in the embodiments of the present application, the technical solution of the present application has at least the following advantages:

[0148] 1. Improve security and transparency:

[0149] By storing the root hash of the whitelist on-chain, we achieve on-chain proof of whitelist verification, ensuring data immutability and high transparency. Using public-private key pairs and the Merkle tree structure, we achieve data integrity verification, further improving system security.

[0150] 2. Reduce centralized trust costs:

[0151] This application reduces reliance on centralized databases and reduces trust costs by storing whitelist proofs locally off-chain and combining them with on-chain verification. This approach avoids the potential for arbitrary tampering with centralized databases, prevents over-issuance and random issuance of whitelists, and improves the credibility of the system.

[0152] 3. Optimize storage and read / write costs:

[0153] By storing whitelist proofs locally off-chain and only storing the root hash value on-chain, the read and write costs of on-chain storage are significantly reduced. Compared with traditional mapping structure storage methods, this method reduces on-chain resource consumption and improves system operation efficiency.

[0154] 4. Efficient verification process:

[0155] This application describes in detail the implementation steps from generating public and private key pairs, organizing public key lists, constructing Merkle trees, and verifying the process, ensuring the efficiency and accuracy of the verification process. When a user calls a smart contract, by passing in a verification path (proof) and using the verification method, they can quickly verify whether the user is on the whitelist, ensuring the efficient operation of the system.

[0156] Therefore, in summary, this application uses an innovative whitelist verification method combined with on-chain and off-chain verification mechanisms to not only improve the security and transparency of the system, reduce centralized trust costs, but also optimize storage and read-write costs, ensuring the efficiency and reliability of smart contracts in practical applications.

[0157] The following are device embodiments of the present application, which can be used to implement the method embodiments of the present application. For details not disclosed in the device embodiments of the present application, please refer to the method embodiments of the present application.

[0158] Figure 4 This is a schematic diagram of the structure of the whitelist verification device for the smart contract provided in the embodiment of the present application. Figure 4 As shown, the whitelist verification device of the smart contract includes:

[0159] The acquisition module 401 is configured to acquire a public key whitelist to obtain a public key list;

[0160] The processing module 402 is configured to sort the elements in the public key list and process the public key list according to the number of elements in the public key list to obtain an ordered public key list;

[0161] Operation module 403 is configured to perform a hash operation on each pair of public keys in the ordered public key list to generate a corresponding hash value, recursively perform a combined hash operation on the hash values ​​generated in the previous layer until a root hash value is obtained, and store the root hash value in the state of the smart contract;

[0162] A construction module 404 is configured to determine the sibling nodes and parent nodes of the public key in the binary tree, and recursively determine the sibling nodes in each level to construct a verification path;

[0163] The comparison module 405 is configured to perform a hash operation on the public key and calculate the combined hash value step by step using the verification path until a final hash value is obtained. The final hash value is compared with the root hash value. If they are equal, the verification passes; otherwise, the verification fails.

[0164] Verification module 406 is configured to respond to the user's call to the smart contract operation, obtain the verification path of the user's corresponding public key, pass the verification path as a parameter, and call the verification method before the business method that needs to verify the whitelist. If the verification passes, the business logic continues to execute, otherwise the execution is terminated.

[0165] In some embodiments, Figure 4 The acquisition module 401 generates a public-private key pair using an elliptic curve algorithm, sets the public-private key pair to be visible to the business, and organizes and generates a public key whitelist according to the business requirements provided by the business party to obtain a public key list.

[0166] In some embodiments, Figure 4 The processing module 402 arranges the elements in the public key list in ascending order and determines the number of elements in the public key list. When the number of elements in the public key list is an odd number, the last element in the public key list is copied to the public key list so that the length of the public key list is an even number, thereby obtaining an ordered public key list, wherein the length of the ordered public key list is an even number.

[0167] In some embodiments, Figure 4 The operation module 403 traverses the ordered public key list, performs hash operations on each pair of adjacent public keys in turn according to a preset step size, obtains the hash value of each pair of public keys, and stores the hash value in the hash value list; performs a combined hash operation on each pair of hash values ​​in the hash value list to generate a new hash value list, and recursively performs a combined hash operation on each pair of hash values ​​in the new hash value list until the length of the generated new hash value list is 1, thereby obtaining the root hash value.

[0168] In some embodiments, Figure 4 The construction module 404 traverses the hash value list of nodes in each layer corresponding to the binary tree, determines the current traversal index, and determines the sibling node index of the current node in the current layer; determines the parent node index of the current node in the previous layer, and determines the sibling node index of the parent node in its layer; adds the hash value of the sibling node of the current layer and the hash value of the sibling node of the parent node in the previous layer to the verification path array in sequence, and recursively reaches the binary tree layer corresponding to the root hash value to construct a complete verification path array.

[0169] In some embodiments, Figure 4 The comparison module 405 defines a verification method in the smart contract, where the return value of the verification method is a Boolean type; the caller's public key is used as an input parameter of the verification method, and the hash value of the public key is calculated to obtain an initial hash value; the initial hash value is combined with the first hash value in the verification path to obtain a first combined hash value; the generated first combined hash value is recursively combined with the next hash value in the verification path until all hash values ​​in the verification path are used to obtain a final hash value; the final hash value is compared with the root hash value stored in the smart contract state. If they are equal, the verification passes and true is returned; if they are not equal, the verification fails and false is returned.

[0170] In some embodiments, Figure 4 When a user calls a smart contract, the verification module 406 sends a request to the server, uses the user's public key to obtain the corresponding verification path, and passes the obtained verification path as a parameter to the smart contract; uses the smart contract to call the verification method before each business method that needs to verify the whitelist, so as to verify according to the user's public key and verification path; uses the verification method to perform a hash operation on the user's public key, and calculates the combined hash value step by step through the verification path until the final hash value is obtained, and compares the final hash value with the root hash value stored in the smart contract state; if the final hash value is equal to the root hash value, the verification is passed, and the smart contract continues to execute the business logic; if the final hash value is not equal to the root hash value, the verification fails, and the smart contract terminates execution.

[0171] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0172] Figure 5 Schematic diagram of the structure of the electronic device 5 provided in the embodiment of the present application. Figure 5 As shown, the electronic device 5 of this embodiment includes: a processor 501, a memory 502, and a computer program 503 stored in the memory 502 and executable on the processor 501. When the processor 501 executes the computer program 503, the steps of the above-mentioned method embodiments are implemented. Alternatively, when the processor 501 executes the computer program 503, the functions of the modules / units in the above-mentioned device embodiments are implemented.

[0173] For example, the computer program 503 may be divided into one or more modules / units, which are stored in the memory 502 and executed by the processor 501 to implement the present application. The one or more modules / units may be a series of computer program instruction segments capable of implementing specific functions, and the instruction segments are used to describe the execution process of the computer program 503 in the electronic device 5.

[0174] The electronic device 5 may be a desktop computer, a notebook, a PDA, a cloud server, or other electronic device. The electronic device 5 may include but is not limited to a processor 501 and a memory 502. Those skilled in the art will appreciate that Figure 5 It is only an example of the electronic device 5 and does not constitute a limitation of the electronic device 5. It may include more or fewer components than shown in the figure, or a combination of certain components, or different components. For example, the electronic device may also include input and output devices, network access devices, buses, etc.

[0175] The processor 501 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0176] The memory 502 can be an internal storage unit of the electronic device 5, such as a hard drive or memory of the electronic device 5. The memory 502 can also be an external storage device of the electronic device 5, such as a plug-in hard drive, a Smart Media Card (SMC), a Secure Digital (SD) card, a flash memory card, etc. equipped on the electronic device 5. Furthermore, the memory 502 can include both an internal storage unit of the electronic device 5 and an external storage device. The memory 502 is used to store computer programs and other programs and data required by the electronic device. The memory 502 can also be used to temporarily store data that has been output or is about to be output.

[0177] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0178] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.

[0179] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0180] In the embodiments provided in this application, it should be understood that the disclosed apparatus / computer equipment and methods can be implemented in other ways. For example, the apparatus / computer equipment embodiments described above are merely schematic. For example, the division of modules or units is merely a logical function division. In actual implementation, there may be other division methods. Multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection of the apparatus or unit, which may be electrical, mechanical or other forms.

[0181] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0182] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0183] If the integrated module / unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the process in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and when the computer program is executed by the processor, it can implement the steps of the above-mentioned various method embodiments. The computer program may include computer program code, which may be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium. It should be noted that the content contained in the computer-readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electric carrier signals and telecommunication signals.

[0184] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present application, and should all be included in the scope of protection of the present application.

Claims

1. A whitelist verification method for smart contracts, characterized in that: include: Get the public key whitelist to get the public key list; Sorting the elements in the public key list, and processing the public key list according to the number of elements in the public key list to obtain an ordered public key list; Perform a hash operation on each pair of public keys in the ordered public key list to generate a corresponding hash value, recursively perform a combined hash operation on the hash values ​​generated in the previous layer until a root hash value is obtained, and store the root hash value in the state of the smart contract; Determine the sibling nodes and parent nodes of the public key in the binary tree, and recursively determine the sibling nodes in each level to build a verification path; Performing a hash operation on the public key and calculating the combined hash value step by step using the verification path until a final hash value is obtained, and comparing the final hash value with the root hash value. If they are equal, verification passes; otherwise, verification fails. In response to the user calling the smart contract operation, the verification path of the user's corresponding public key is obtained, and the verification path is passed in as a parameter. The verification method is called before the business method that needs to verify the whitelist. If the verification passes, the business logic continues to execute, otherwise the execution is terminated.

2. The method according to claim 1, characterized in that The public key whitelist is obtained to obtain a public key list, including: Generate a public-private key pair using an elliptic curve algorithm, set the public-private key pair to be visible to the business, and organize and generate the public key whitelist according to the business requirements provided by the business party to obtain the public key list.

3. The method according to claim 1, characterized in that The step of sorting the elements in the public key list and processing the public key list according to the number of elements in the public key list to obtain an ordered public key list includes: Arrange the elements in the public key list in ascending order and determine the number of elements in the public key list. When the number of elements in the public key list is an odd number, copy the last element in the public key list to the public key list so that the length of the public key list is an even number, thereby obtaining the ordered public key list, wherein the length of the ordered public key list is an even number.

4. The method according to claim 1, wherein The step of performing a hash operation on each pair of public keys in the ordered public key list to generate a corresponding hash value, and recursively performing a combined hash operation on the hash values ​​generated in the previous layer until a root hash value is obtained, including: The ordered public key list is traversed, and hash operations are performed on each pair of adjacent public keys in turn according to a preset step size to obtain hash values ​​of each pair of public keys, and the hash values ​​are stored in a hash value list; a combined hash operation is performed on each pair of hash values ​​in the hash value list to generate a new hash value list, and a recursive combined hash operation is performed on each pair of hash values ​​in the new hash value list until the length of the generated new hash value list is 1, thereby obtaining the root hash value.

5. The method according to claim 1, wherein Determining the sibling nodes and parent nodes of the public key in the binary tree, and recursively determining the sibling nodes in each level to construct a verification path, includes: Traverse the hash value list of nodes in each layer corresponding to the binary tree, determine the current traversal index, and determine the sibling node index of the current node in the current layer; Determine the parent node index of the current node in the previous layer, and determine the sibling node index of the parent node in its layer; Add the hash values ​​of the sibling nodes of the current layer and the hash values ​​of the sibling nodes of the parent node of the previous layer to the verification path array in sequence, and recursively reach the binary tree layer corresponding to the root hash value to construct a complete verification path array.

6. The method according to claim 1, characterized in that The hash operation is performed on the public key, and the combined hash value is calculated step by step using the verification path until a final hash value is obtained, and the final hash value is compared with the root hash value. If they are equal, the verification passes, otherwise the verification fails, including: A verification method is defined in the smart contract, wherein the return value of the verification method is a Boolean type; Taking the caller's public key as an input parameter of the verification method, calculating the hash value of the public key to obtain an initial hash value; Performing a combined hash operation on the initial hash value and the first hash value in the verification path to obtain a first combined hash value; recursively performing a combined hash operation on the generated first combined hash value and the next hash value in the verification path until all hash values ​​in the verification path are used to obtain the final hash value; The final hash value is compared with the root hash value stored in the smart contract state. If they are equal, the verification passes and true is returned; if they are not equal, the verification fails and false is returned.

7. The method according to claim 6, characterized in that In response to the user calling the smart contract operation, the verification path of the user's corresponding public key is obtained, and the verification path is passed as a parameter. The verification method is called before the business method that needs to verify the whitelist. If the verification passes, the business logic continues to execute, otherwise the execution is terminated, including: When a user calls a smart contract, a request is sent to the server, the corresponding verification path is obtained using the user's public key, and the obtained verification path is passed as a parameter to the smart contract; Utilize the smart contract to call the verification method before each business method that requires whitelist verification, so as to perform verification based on the user's public key and verification path; Performing a hash operation on the user's public key using the verification method, and calculating the combined hash value step by step through the verification path until a final hash value is obtained, and comparing the final hash value with the root hash value stored in the smart contract state; If the final hash value is equal to the root hash value, the verification is passed and the smart contract continues to execute the business logic. If the final hash value is not equal to the root hash value, the verification fails and the smart contract terminates execution.

8. A whitelist verification device for a smart contract, characterized in that: include: an acquisition module, configured to acquire a public key whitelist to obtain a public key list; a processing module configured to sort the elements in the public key list and process the public key list according to the number of elements in the public key list to obtain an ordered public key list; an operation module configured to perform a hash operation on each pair of public keys in the ordered public key list to generate a corresponding hash value, recursively perform a combined hash operation on the hash values ​​generated in the previous layer until a root hash value is obtained, and store the root hash value in the state of the smart contract; A construction module, configured to determine the sibling nodes and parent nodes of the public key in the binary tree, and recursively determine the sibling nodes in each level to construct a verification path; a comparison module configured to perform a hash operation on the public key, and calculate a combined hash value step by step using the verification path until a final hash value is obtained, and compare the final hash value with the root hash value; if they are equal, verification passes; otherwise, verification fails; The verification module is configured to respond to the user's call to the smart contract operation, obtain the verification path of the user's corresponding public key, pass the verification path as a parameter, and call the verification method before the business method that needs to verify the whitelist. If the verification passes, the business logic continues to execute, otherwise the execution is terminated.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images