Verification method based on block chain and electronic equipment

Abstract

The invention discloses a block chain-based verification method and electronic equipment, and the method comprises the steps: carrying out the analysis of a transaction request, and obtaining identity certificate data carried by the transaction request; wherein the identity certificate data is generated based on the relationship between the transaction account and the account blacklist and the version information of the account blacklist; calculating the identity data according to a preset function to obtain to-be-verified data; generating first verification data according to a public key corresponding to the account blacklist and the to-be-verified data, and generating second verification data according to the public generator and the to-be-verified data; the public generator is a preset public parameter; and verifying the transaction request according to the identity proof data, the first verification value and the second verification value. According to the technical scheme, the volume of the verification data is compressed, the data transmission amount and the calculation amount of the block chain node in the verification process are reduced, and the verification speed of the transaction request can be remarkably improved.

Description

Technical Field

[0001] This application belongs to the field of blockchain technology, specifically relating to a blockchain-based verification method and electronic device. Background Technology

[0002] In scenarios such as financial compliance, digital identity authentication, content security, and decentralized applications, there is a widespread need for access control to sensitive lists (such as credit blacklists and databases of non-compliant accounts). Before business operations, it is typically necessary to verify whether an entity (such as a user's identity or wallet address) is not on a blacklist to ensure compliance and system security. A common approach is for regulators to directly upload the blacklist in plaintext or as a simple hash set to the blockchain and store it in the smart contract's storage space. When a user initiates a transaction and needs to verify whether the account address is on the blacklist, the smart contract parses the account address in the transaction signature and determines whether the address exists through traversal or search operations. However, this verification method requires multiple hash calculations based on the complete path of the proof for each verification, resulting in relatively poor efficiency. Summary of the Invention

[0003] The purpose of this application is to provide a blockchain-based verification method and electronic device to improve the efficiency of blockchain-based verification to a certain extent.

[0004] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0005] According to one aspect of the embodiments of this application, a blockchain-based verification method is provided, comprising: The transaction request is parsed to obtain the identity verification data carried in the transaction request; wherein, the identity verification data is generated based on the relationship between the transaction account and the account blacklist, as well as the version information of the account blacklist; The identity verification data is calculated according to a preset function to obtain the data to be verified; First verification data is generated based on the public key corresponding to the account blacklist and the data to be verified; second verification data is generated based on the public generator and the data to be verified; the public generator is a pre-set public parameter. The transaction request is verified based on the identity verification data, the first verification value, and the second verification value.

[0006] According to one aspect of the embodiments of this application, a blockchain-based verification device is provided, comprising: The parsing module is used to parse the transaction request to obtain the identity verification data carried by the transaction request; wherein, the identity verification data is generated based on the relationship between the transaction account and the account blacklist, as well as the version information of the account blacklist; The calculation module is used to calculate the identity verification data according to a preset function to obtain the data to be verified; The verification data generation module is used to generate first verification data based on the public key corresponding to the account blacklist and the data to be verified, and to generate second verification data based on the public generator and the data to be verified; the public generator is a pre-set public parameter. The verification module is used to verify the transaction request based on the identity verification data, the first verification value, and the second verification value.

[0007] In one embodiment of this application, the apparatus further includes a proof generation module, specifically used for: Based on the relationship between the transaction account and each account in the account blacklist, non-existence evidence is generated corresponding to the transaction account; wherein, the non-existence evidence indicates whether the transaction account belongs to the account blacklist. Calculate the response to the challenge based on the non-existence evidence according to the challenge response mechanism; The identity verification data is generated based on the non-existent evidence, the response, and the version information of the account blacklist.

[0008] In one embodiment of this application, the proof generation module is specifically used for: Calculate the deviation between the account address of the transaction account and the account addresses of each account in the account blacklist; The non-existence evidence corresponding to the transaction account is calculated based on the sum of the various deviations.

[0009] In one embodiment of this application, the proof generation module is specifically used for: If the sum of all deviations is a set value, then the non-existence evidence is rejected, or the non-existence evidence is set to a predetermined value.

[0010] In one embodiment of this application, the proof generation module is specifically used for: Select a random number, and calculate a commitment based on the public generator; The challenge is obtained by calculating the version information of the transaction account, the non-existence evidence, the commitment, and the account blacklist based on the preset function; Generate a response corresponding to the challenge.

[0011] In one embodiment of this application, the proof generation module is specifically used for: The identity verification data is generated by combining the commitment, the response, the non-existence evidence, and the version information of the account blacklist.

[0012] In one embodiment of this application, the identity verification data includes a commitment, a response, and non-existence evidence. The commitment is generated based on a random number, the response is generated based on a challenge-response mechanism, and the non-existence evidence indicates whether the transaction account belongs to the account blacklist. The calculation module is specifically used for: The commitment, the response, the non-existence evidence, and the transaction account are calculated according to a preset function to obtain the data to be verified.

[0013] In one embodiment of this application, the verification data generation module is specifically used for: Using the public key corresponding to the account blacklist as the base and the data to be verified as the exponent, a public key exponent is calculated; the product of the public key exponent and the commitment is used as the first verification data. The response is used as a power of the publicly disclosed generator to calculate the second verification data.

[0014] In one embodiment of this application, the identity verification data includes non-existence evidence and version information of the account blacklist, wherein the non-existence evidence indicates whether the transaction account belongs to the account in the account blacklist; The verification module is specifically used for: If the version information of the account blacklist in the identity verification data is inconsistent with the current publicly available version information of the account blacklist, the verification is determined to fail. If the version information of the account blacklist in the identity verification data is consistent with the current publicly available version information of the account blacklist, then the relationship between the non-existent evidence and the preset value is detected. If the non-existent evidence matches the preset value, the verification is deemed to have failed. If the non-existent evidence is inconsistent with the preset value, then the relationship between the first verification value and the second verification value is detected; If the first check value and the second check value are the same, the check is determined to be successful; if the first check value and the second check value are different, the check is determined to be unsuccessful.

[0015] According to one aspect of the embodiments of this application, a computer-readable medium is provided, on which a computer program is stored, which, when executed by a processor, implements the blockchain-based verification method as described above.

[0016] According to one aspect of the embodiments of this application, an electronic device is provided, the electronic device comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor executes the executable instructions to cause the electronic device to perform a blockchain-based verification method as described in the above technical solutions.

[0017] According to one aspect of the embodiments of this application, a computer program product or computer program is provided, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the blockchain-based verification method as described above.

[0018] In the technical solution provided in this application embodiment, the transaction request is parsed to obtain the identity verification data carried in the transaction request. This identity verification data is generated based on the relationship between the transaction account and the account blacklist, as well as the version information of the account blacklist. The identity verification data is calculated according to a preset function to obtain data to be verified. First verification data is generated based on the public key corresponding to the account blacklist and the data to be verified, and second verification data is generated based on public parameters and the data to be verified. The public parameters are pre-set public parameters. The transaction request is verified based on the identity verification data, the first verification value, and the second verification value. Thus, the identity verification data is processed by a preset function to obtain the data to be verified, and then two types of verification data are generated based on the data to be verified, instead of directly comparing the original transaction data with the complete blacklist. This layered processing method can significantly compress the volume of verification data, reducing the amount of data transmission and computation in the blockchain node verification process. At the same time, the generation logic of the dual verification data is simple and clear, requiring no complex cross-node data interaction, which can significantly improve the verification speed of transaction requests and adapt to the needs of high-frequency trading scenarios in blockchain.

[0019] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0020] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0021] Figure 1 An exemplary system architecture block diagram illustrating the application of the technical solution of this application is shown schematically.

[0022] Figure 2 A flowchart illustrating a blockchain-based verification method provided in one embodiment of this application is shown schematically.

[0023] Figure 3 A flowchart illustrating a blockchain-based verification method provided in one embodiment of this application is shown schematically.

[0024] Figure 4 A flowchart illustrating a blockchain-based verification method provided in one embodiment of this application is shown schematically.

[0025] Figure 5 A schematic diagram of the structure of the blockchain-based verification device provided in the embodiments of this application is shown.

[0026] Figure 6 A schematic diagram of a computer system architecture suitable for implementing the embodiments of this application is shown. Detailed Implementation

[0027] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.

[0028] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0029] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0030] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0031] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0032] It is understood that in the specific implementation of this application, customer information (such as transaction information, reconciliation data) and other related data are involved. When the above embodiments of this application are applied to specific products or technologies, customer permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0033] Figure 1 An exemplary system architecture block diagram illustrating the application of the technical solution of this application is shown schematically.

[0034] like Figure 1 As shown, the system architecture 100 may include terminal devices 110, a network 120, and a server 130. Terminal devices 110 may include smartphones, tablets, laptops, smart voice interaction devices, smart home appliances, in-vehicle terminals, etc. Server 130 may be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services. Network 120 may be a communication medium of various connection types capable of providing a communication link between terminal devices 110 and server 130, such as a wired communication link or a wireless communication link.

[0035] Depending on the implementation requirements, the system architecture in this application embodiment can have any number of terminal devices, networks, and servers. For example, server 130 can be a server group composed of multiple server devices. In addition, the technical solutions provided in this application embodiment can be applied to terminal device 110, or to server 130, or can be implemented jointly by terminal device 110 and server 130. This application does not impose any special limitations on this.

[0036] The blockchain-based verification method provided in this application will be described in detail below with reference to specific implementation methods.

[0037] Figure 2 A flowchart illustrating a blockchain-based verification method according to an embodiment of this application is shown. This method can be implemented by a blockchain-based verification device or system. Figure 2As shown, the blockchain-based verification method provided in this embodiment includes steps 210 to 250, as detailed below: Step 210: Parse the transaction request to obtain the identity verification data carried in the transaction request; wherein, the identity verification data is generated based on the relationship between the transaction account and the account blacklist, as well as the version information of the account blacklist.

[0038] Specifically, a transaction request is a business operation instruction issued by the transaction initiator, such as transferring funds or modifying account information. A transaction request may include information such as the initiating account address, the operation content, and identity credentials. Parsing a transaction request refers to extracting identity verification data from the transaction instructions (such as transfers and contract call requests) received from the blockchain network. Identity verification data is the core data carrier used to characterize the legitimacy of a transaction account. It is not a traditional account password or digital certificate, but rather verification-specific data generated by combining the relationship between the transaction account and the account blacklist, as well as the account blacklist version information. The transaction account is the blockchain account entity that initiates the transaction request, corresponding to a unique account address or identifier. The account blacklist is a pre-maintained list of high-risk accounts in the blockchain system, containing accounts with malicious transactions, fraud, or default behavior, with the aim of intercepting transaction requests from such accounts. The relationship between a transaction account and the account blacklist refers to whether the transaction account belongs to an account on the blacklist. The account blacklist version information is a unique identifier (such as a version number or timestamp) marking the update and iteration of the account blacklist data. Because blockchain is a distributed system, each node needs to synchronize the latest blacklist through version information to avoid false judgments due to data lag. Identity verification data is generated based on the specified content mentioned above; its data volume is constant and will not be excessive, thus reducing storage and transmission overhead, which in turn improves verification efficiency and saves storage resources used for verification.

[0039] Step 220: Calculate the identity verification data according to the preset function to obtain the data to be verified.

[0040] Specifically, the preset function is an algorithm function pre-defined and agreed upon by the entire blockchain system. It can be selected according to business needs (such as the hash function SHA-256, the symmetric encryption function AES, etc.), and possesses deterministic and irreversible characteristics (if the inputs are the same, the outputs will be the same, and the outputs cannot be used to deduce the inputs). This ensures the consistency and security of data processing. Identity verification data is input into the predefined algorithm function for data transformation, compression, or feature extraction, and the output is the data to be verified.

[0041] Step 230: Generate the first verification data based on the public key corresponding to the account blacklist and the data to be verified, and generate the second verification data based on the public generator and the data to be verified; the public generator is a pre-set public parameter.

[0042] Specifically, based on the data to be verified, two independent sets of verification data are generated by combining two different parameters: the blacklist public key and the public generator. The public key corresponding to the account blacklist is a cryptographic key paired with the private key of the account blacklist data. It is generated and published by the blacklist management node of the blockchain system. In this embodiment, the blacklist management node is called the regulator, which is a trusted node. The data to be verified and the blacklist public key can generate the first verification data through cryptographic operations (such as public key encryption and signature verification).

[0043] Public generators are pre-defined public parameters that are publicly available across the entire blockchain network. They can be set by community consensus or system administrators and are characterized by being open, transparent, and tamper-proof, requiring no secrecy. The data to be verified and the public generators can be used to generate second verification data through preset rules (such as hash operations and modulo operations).

[0044] Step 240: Verify the transaction request based on the identity verification data, the first verification value, and the second verification value.

[0045] Specifically, verification can be performed based on relevant information in the identity verification data, or based on whether the first verification value and the second verification value are consistent, or a combination of all three can be used for verification.

[0046] In one embodiment, the identity verification data includes non-existence evidence and version information of the account blacklist. The non-existence evidence indicates whether the transaction account belongs to the account blacklist. During the verification process, the version information of the account blacklist in the identity verification data can be checked to see if it is consistent with the currently publicly available version of the account blacklist. If they are consistent, it means the blacklist data is accurate, the verification is considered successful, and the transaction request is executed. If they are inconsistent, it means the blacklist data has changed. For example, the transaction initiator may have tampered with the blacklist data to remove the transaction account from the blacklist. In this case, for security reasons, the verification is considered unsuccessful, and the transaction request is blocked.

[0047] In one embodiment, it can be detected whether the first verification value and the second verification value are consistent. If they are consistent, it indicates that the data to be verified is accurate, and thus the identity verification data carried in the transaction request is accurate. Therefore, the verification is considered successful, and the transaction request can be executed. If they are inconsistent, it indicates that the identity verification data is inaccurate. Therefore, the verification is considered unsuccessful, and the transaction request is blocked.

[0048] In one embodiment, the accuracy of the blacklist version can be checked first, followed by the accuracy of the identity verification data. Specifically, this includes: if the version information of the account blacklist in the identity verification data is inconsistent with the currently publicly available version information of the account blacklist, the verification fails; if the version information of the account blacklist in the identity verification data is consistent with the currently publicly available version information of the account blacklist, the relationship between non-existent evidence and a preset value is checked; if the non-existent evidence is consistent with the preset value, the verification fails; if the non-existent evidence is inconsistent with the preset value, the relationship between a first verification value and a second verification value is checked; if the first verification value and the second verification value are consistent, the verification passes; if the first verification value and the second verification value are inconsistent, the verification fails.

[0049] In the technical solution provided in this application embodiment, the transaction request is parsed to obtain the identity verification data carried in the transaction request. This identity verification data is generated based on the relationship between the transaction account and the account blacklist, as well as the version information of the account blacklist. The identity verification data is calculated according to a preset function to obtain data to be verified. First verification data is generated based on the public key corresponding to the account blacklist and the data to be verified, and second verification data is generated based on public parameters and the data to be verified. The public parameters are pre-set public parameters. The transaction request is verified based on the identity verification data, the first verification value, and the second verification value. Thus, the identity verification data is processed by a preset function to obtain the data to be verified, and then dual verification data is generated based on the data to be verified, instead of directly comparing the original transaction data with the complete blacklist. This layered processing method can significantly compress the volume of verification data, reducing the amount of data transmission and computation in the blockchain node verification process. At the same time, the generation logic of the dual verification data is simple and clear, requiring no complex cross-node data interaction, which can significantly improve the verification speed of transaction requests and adapt to the needs of high-frequency trading scenarios in blockchain.

[0050] Figure 3 A flowchart illustrating a blockchain-based verification method provided in one embodiment of this application is shown. Figure 3 As shown, the blockchain-based verification method provided in this embodiment includes steps 310 to 370, as detailed below: Step 310: Generate non-existence evidence corresponding to the trading account based on the relationship between the trading account and each account in the account blacklist; wherein, the non-existence evidence indicates whether the trading account belongs to the account blacklist.

[0051] Specifically, the relationship between a trading account and the accounts on the blacklist refers to whether the trading account is identical to any of the accounts on the blacklist. When calculating non-existence evidence, the deviation between the trading account and the blacklisted accounts is used to represent the relationship between them.

[0052] In one embodiment, the non-existence evidence calculation process includes: calculating the deviation between the account address of the transaction account and each account address in the account blacklist; and calculating the non-existence evidence corresponding to the transaction account based on the sum of the deviations.

[0053] Transaction accounts have a unique account address on the blockchain, and there are also blacklists for these accounts. The elements in the string are the account addresses of each blacklisted account. Construct a polynomial rooted at the blacklist elements:

[0054] Where n is the number of blacklisted accounts. Let i be the address of the i-th account in the blacklist. Let x be a large prime number. Assuming the account address of the trading account is x, substitute x into the polynomial above, calculate the deviation between the account address of the trading account and each account address in the blacklist, and sum the deviations to obtain the polynomial value of the trading account.

[0055] Then, based on the publicly generated metadata g, non-existence evidence corresponding to the transaction account is calculated. :

[0056] In one embodiment, after calculating the non-existence evidence, the non-existence evidence is 0, which indicates that a certain address exists in the account blacklist. Its address is the same as the account address x of the trading account, that is... This leads to the polynomial sum corresponding to the trading account If the sum of all deviations equals a set value, then the trading account is on a blacklist, and therefore the generation of non-existent evidence is refused, or the non-existent evidence is set to a predetermined value, such as 0.

[0057] Step 320: Calculate the response to the challenge based on non-existence evidence according to the challenge response mechanism.

[0058] Specifically, the challenge-response mechanism refers to the method of generating a corresponding response based on a challenge, and determining whether the certifier possesses legitimate identity / authority / secrets by verifying the validity of the response. This step utilizes the challenge-response mechanism's challenge-response generation process.

[0059] In one embodiment, the response generation process includes: selecting a random number, calculating a commitment based on the random number according to a publicly available generator; calculating the version information of the transaction account, non-existence evidence, commitment, and account blacklist according to a preset function to obtain a challenge; and generating a response corresponding to the challenge.

[0060] First, select a random number. , The calculation scope of the technical solution in this application is based on... promise :

[0061] Then based on the address of the transaction account Non-existent evidence ,promise Version information of the account blacklist Computational Challenge :

[0062] Here, H is a cryptographically secure hash function.

[0063] Then generate the challenge. Subsequently, the regulator generates a computational response. :

[0064] in, The private key for the blacklist of accounts held by regulators.

[0065] Step 330: Generate identity verification data based on the version information of non-existent evidence, response, and account blacklist.

[0066] Specifically, will commit ,response Non-existent evidence Version information of the account blacklist Combine them to generate identity verification data. .

[0067] In one embodiment, regulators generate an account blacklist based on a hash function. version number , Version number On-chain storage.

[0068] Step 340: Parse the transaction request to obtain the identity verification data carried in the transaction request; wherein, the identity verification data is generated based on the relationship between the transaction account and the account blacklist, as well as the version information of the account blacklist.

[0069] Step 340 is the same as step 210 above, and will not be repeated here.

[0070] Step 350: Calculate the commitment, response, non-existence evidence, and transaction account according to the preset function to obtain the data to be verified.

[0071] Specifically, identity verification data Including commitments ,response Non-existent evidence Version information of the account blacklist When calculating the data to be verified, extract the commitment from it. Non-existent evidence Version information of the account blacklist Then, combined with the account address x of the transaction account, the data to be verified is calculated. :

[0072] Step 360: Using the public key corresponding to the account blacklist as the base and the data to be verified as the exponent, calculate the public key exponent; use the product of the public key exponent and the commitment as the first verification data; use the response as the power of the public generator to calculate the second verification data.

[0073] Specifically, the public key exponentiation is... Where A is the private key. The corresponding public key, The first verification data is The second verification data is .

[0074] Step 370: Verify the transaction request based on the identity verification data, the first verification value, and the second verification value.

[0075] In one embodiment, the verification process is executed by a smart contract. The smart contract first compares the submitted identity verification data with the blacklisted version. If the information matches the current publicly available version of the account blacklist, and they do not match, it means the account blacklist has been updated, the identity verification data is invalid, and the verification failed. If they match, proceed to the next step.

[0076] In one embodiment, if the smart contract detects that the blacklist version information is accurate, it continues to verify whether the non-existence evidence matches a preset value. The preset value here is 1. That is, it detects... ,if This indicates that the trading account is on the blacklist. The verification failed. This means that, assuming the user is honest, the transaction account they submitted is not on the blacklist. At this point, the verification can be considered successful. Optionally, to improve the accuracy of the verification, if... If the verification still fails, the subsequent verification process will continue.

[0077] In one embodiment, when both the blacklist version and the non-existence evidence verification pass, the system continues to check whether the first verification value and the second verification value are equal. If the user is honest and actually obtains the proof generated by the regulator, the equation will always hold, meaning the two verification values ​​will always be equal. The principle is as follows:

[0078] If the identity verification data in the transaction request is accurate, then Therefore Established.

[0079] If the two check values ​​are not equal, that is If the verification fails, it means the identity verification data in the transaction request is forged, and the verification fails. Only when the smart contract passes the above three verifications can the transaction be confirmed. That is, the account address of the trading account. If you are not on the blacklist and the verification is successful, the transaction can be executed.

[0080] In the technical solution provided in this embodiment, commitments, responses, non-existent evidence, and transaction accounts are integrated and calculated using a preset function to generate simplified data to be verified, rather than directly verifying the original data, thus significantly reducing the data processing volume. The exponentiation operation logic is simple and highly parallel, allowing blockchain nodes to quickly complete the generation and verification of dual-verification data without complex cross-node data interaction. The overall process is lightweight, effectively reducing the computing power consumption of nodes, improving the response speed of transaction verification, and adapting to the business needs of high-frequency blockchain transactions.

[0081] The implementation process of the technical solution of this application will be illustrated below with a specific embodiment.

[0082] Figure 4 A flowchart illustrating a blockchain-based verification method provided in one embodiment of this application is shown schematically.

[0083] The technical solution of this application is based on the mathematical structure of finite fields and cyclic groups. Let... It is a large prime number. For an order of cyclic group For public generators, For a cryptographically secure hash function, all operations are performed in a finite field. In the process. For example... Figure 4As shown, the blockchain-based verification method provided in this embodiment includes four parts: initialization phase, proof generation phase, contract verification phase, and blacklist dynamic update phase. The system includes three roles: regulator, user, and validator (smart contract), where the regulator is trusted.

[0084] I. Initialization Phase S1, Regulators hold private blacklists and private key private key The corresponding public key is .

[0085] S2, to ensure Without revealing the information, regulators construct a polynomial rooted at the elements of the blacklist:

[0086] and define for Non-existent evidence:

[0087] This mapping transforms set membership determination into an algebraic problem of whether a group element is an identity element, achieving algebraic encoding and privacy hiding of blacklist information, without requiring regulators to disclose it. However, it can be accessed through Verify any Due to the difficulty of discrete logarithms, attackers cannot obtain... Reverse push or .

[0088] According to the properties of polynomial roots, we have: ;on the contrary, .

[0089] S3. The regulator calculates the blacklist hash value as the public version number, that is, generates the current blacklist set based on the hash function. version number , .

[0090] S4, Smart Contract Version Number Records are uploaded to the blockchain and a query interface is provided.

[0091] Assumption , For a limited domain, regulators hold private blacklists. The private key is The corresponding public key is The regulators construct a polynomial rooted at the elements of the blacklist: For ease of calculation, assume... Corresponding blacklist version information .

[0092] II. Proof Generation Stage S5. The user initiates an authentication request. When the user wants to authenticate based on their account address... When sending a transaction on-chain, proof of not being on the blacklist must first be generated; otherwise, the contract will reject it directly. Users send their account addresses to regulators. .

[0093] S6, Regulators based on Perform local verification.

[0094] Regulators received account addresses Then, calculate the root polynomial in The value at the location :

[0095] S7. Determine if the user is on the blacklist. If Then there exists a certain ,make Therefore, the entire product is zero. If Then all In a finite field, the product of non-zero elements is still non-zero, therefore: .

[0096] S8. Deny the request. ,Right now At that time, regulators refused to respond.

[0097] S9. Generate a temporary random number and calculate the encrypted commitment. If Then the regulators will act according to Generate corresponding non-existent evidence : Then select a random number. Calculation based on promise : .

[0098] S10. Generate a challenge value and calculate the encrypted response, then package it to generate a structured proof. Based on , , And the current blacklist version Computational Challenge : Generate Challenge Subsequently, the regulator generates a computational response. : Finally, regulators will prove... Return it to the user.

[0099] For example, suppose the user initiates an account address The regulator first calculated:

[0100] That is to prove This is true, and at this point, a proof of non-existence is generated:

[0101] The regulator then generates a random number. ,calculate And calculate the challenge based on the hash function. To facilitate calculation, the following assumptions were made. The calculation result is 3.

[0102]

[0103] Then the regulator generates a computational response. :

[0104] Finally, the regulator generates proof. And return the proof to the user:

[0105] III. Proof Generation Stage S11. User receives proof. This proof is the identity verification data.

[0106] S12, The user submits the proof to the blockchain smart contract. When the user receives the proof... Then, construct the transaction, sign it, and then provide proof. Initiate a request to upload to the blockchain.

[0107] S13, Contract Reconstruction Challenge and Verification Proof and Version Number.

[0108] S14. Determine whether the verification passes.

[0109] S15. If the verification fails, the transaction will be rejected.

[0110] S16. If the verification is successful, the transaction will be executed automatically.

[0111] When the smart contract receives the on-chain request parameters, it parses the account address through the transaction signature. Then perform the following verification: First, the smart contract compares the submitted blacklist versions. If the blacklist is not equal to the publicly available one, it means that the blacklist set has been updated, proving that it is invalid and the verification failed. Secondly, smart contract verification ,if This means Verification failed; if This means In the case of user honesty However, this does not mean that the verification has been successful.

[0112] Finally, the smart contract recalculated the challenge value. , Then verify: If the user forges Any value in the value set will cause subsequent validations to fail.

[0113] Clearly, if the user is honest and actually obtains the proof generated by the regulator, the equation must hold, that is:

[0114] If they are not equal, it means the user forged the proof, and the verification fails. Only when the smart contract passes the above three checks can the verification be confirmed. account address If you are not on the blacklist, you can execute the transaction.

[0115] For example, suppose a user tries to forge a and For any Try to find :

[0116] This is equivalent to solving:

[0117] The user is unaware and Under the discrete logarithm difficulty assumption, it is impossible to fabricate a value for . , making It holds true, and the hash function guarantees collision resistance. The unpredictability, that is, if Then prove It must have been generated by regulators, not forged by attackers.

[0118] Furthermore, if a user replaces their account address with a verifiable proof, it will inevitably lead to problems during the reconstruction challenge. This leads to the failure of the equation verification.

[0119] Proof using the above example For example, Matches the on-chain version, and at the same time ,illustrate Not on the blacklist, final verification check:

[0120] Recalculate the challenge:

[0121] Calculate on the left side:

[0122] Calculate on the right side:

[0123] because ,so ,therefore:

[0124] The equation holds true, and it has finally been proven. The smart contract verification passed, and the on-chain transaction continued to be executed.

[0125] IV. Blacklist Dynamic Update Phase S17. Blacklist Changes. When regulators need to update the blacklist, they only need to update the polynomial and version number rooted in the blacklist.

[0126] S18. Recalculate the hash value to generate a new version number V. new , or written as .

[0127] S19, New Version V new Write it into the blockchain network.

[0128] S20. All older versions failed verification due to version number mismatch.

[0129] Set up a blacklist from Updated to The update operations include: adding new members: ; Deleting a member: ; or a combination of the two.

[0130] The updated polynomial is:

[0131] Obviously for the newly added members ,exist:

[0132] For deleted members ,exist:

[0133] Simultaneously update the blacklist version number. And replace the original version number on the blockchain. .

[0134]

[0135] Proof generated by the technical solution in this embodiment It features a constant size, small data volume, and low storage and transmission overhead; the smart contract verification process requires only one group exponentiation operation and one hash calculation, resulting in high computational efficiency and suitability for high-frequency, large-scale on-chain applications; simultaneously, blacklist updates only require recalculating the version hash, with an operation complexity of O(n log n). It achieves lightweight and efficient dynamic compliance management without the need for a revocation list or additional notification mechanisms.

[0136] It should be noted that although the steps of the method in this application are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0137] The following describes an apparatus embodiment of this application, which can be used to execute the blockchain-based verification method in the above embodiments of this application. Figure 5 A schematic block diagram of a blockchain-based verification device provided in an embodiment of this application is shown. Figure 5 As shown, the blockchain-based verification device provided in this application embodiment includes: The parsing module 510 is used to parse the transaction request to obtain the identity verification data carried by the transaction request; wherein, the identity verification data is generated based on the relationship between the transaction account and the account blacklist, as well as the version information of the account blacklist. The calculation module 520 is used to calculate the identity verification data according to a preset function to obtain the data to be verified; The verification data generation module 530 is used to generate first verification data based on the public key corresponding to the account blacklist and the data to be verified, and to generate second verification data based on the public generator and the data to be verified; the public generator is a pre-set public parameter. The verification module 540 is used to verify the transaction request based on the identity verification data, the first verification value, and the second verification value.

[0138] In one embodiment of this application, the apparatus further includes a proof generation module, specifically used for: Based on the relationship between the transaction account and each account in the account blacklist, non-existence evidence is generated corresponding to the transaction account; wherein, the non-existence evidence indicates whether the transaction account belongs to the account blacklist. Calculate the response to the challenge based on the non-existence evidence according to the challenge response mechanism; The identity verification data is generated based on the non-existent evidence, the response, and the version information of the account blacklist.

[0139] In one embodiment of this application, the proof generation module is specifically used for: Calculate the deviation between the account address of the transaction account and the account addresses of each account in the account blacklist; The non-existence evidence corresponding to the transaction account is calculated based on the sum of the various deviations.

[0140] In one embodiment of this application, the proof generation module is specifically used for: If the sum of all deviations is a set value, then the non-existence evidence is rejected, or the non-existence evidence is set to a predetermined value.

[0141] In one embodiment of this application, the proof generation module is specifically used for: Select a random number, and calculate a commitment based on the public generator; The challenge is obtained by calculating the version information of the transaction account, the non-existence evidence, the commitment, and the account blacklist based on the preset function; Generate a response corresponding to the challenge.

[0142] In one embodiment of this application, the proof generation module is specifically used for: The identity verification data is generated by combining the commitment, the response, the non-existence evidence, and the version information of the account blacklist.

[0143] In one embodiment of this application, the identity verification data includes a commitment, a response, and non-existence evidence. The commitment is generated based on a random number, the response is generated based on a challenge-response mechanism, and the non-existence evidence indicates whether the transaction account belongs to the account blacklist. The calculation module 520 is specifically used for: The commitment, the response, the non-existence evidence, and the transaction account are calculated according to a preset function to obtain the data to be verified.

[0144] In one embodiment of this application, the verification data generation module 530 is specifically used for: Using the public key corresponding to the account blacklist as the base and the data to be verified as the exponent, a public key exponent is calculated; the product of the public key exponent and the commitment is used as the first verification data. The response is used as a power of the publicly disclosed generator to calculate the second verification data.

[0145] In one embodiment of this application, the identity verification data includes non-existence evidence and version information of the account blacklist, wherein the non-existence evidence indicates whether the transaction account belongs to the account in the account blacklist; The verification module 540 is specifically used for: If the version information of the account blacklist in the identity verification data is inconsistent with the current publicly available version information of the account blacklist, the verification is determined to fail. If the version information of the account blacklist in the identity verification data is consistent with the current publicly available version information of the account blacklist, then the relationship between the non-existent evidence and the preset value is detected. If the non-existent evidence matches the preset value, the verification is deemed to have failed. If the non-existent evidence is inconsistent with the preset value, then the relationship between the first verification value and the second verification value is detected; If the first check value and the second check value are the same, the check is determined to be successful; if the first check value and the second check value are different, the check is determined to be unsuccessful.

[0146] The specific details of the blockchain-based verification device provided in the various embodiments of this application have been described in detail in the corresponding method embodiments, and will not be repeated here.

[0147] Figure 6 A schematic block diagram of a computer system architecture for implementing an electronic device according to embodiments of the present application is shown.

[0148] It should be noted that, Figure 6 The computer system 600 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0149] like Figure 6As shown, the computer system 600 includes a central processing unit (CPU) 601, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 602 or programs loaded from storage section 608 into random access memory (RAM). The RAM 603 also stores various programs and data required for system operation. The CPU 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output interface 605 (I / O interface) is also connected to the bus 604.

[0150] The following components are connected to the input / output interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a local area network card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the input / output interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 610 as needed so that computer programs read from it can be installed into the storage section 608 as needed.

[0151] Specifically, according to embodiments of this application, the processes described in the various method flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 609, and / or installed from removable medium 611. When the computer program is executed by central processing unit 601, it performs various functions defined in the system of this application.

[0152] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such transmitted data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0153] 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 application. 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, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0154] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0155] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the methods according to the embodiments of this application.

[0156] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0157] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A blockchain-based verification method, characterized in that, include: The transaction request is parsed to obtain the identity verification data carried in the transaction request; wherein, the identity verification data is generated based on the relationship between the transaction account and the account blacklist, as well as the version information of the account blacklist; The identity verification data is calculated according to a preset function to obtain the data to be verified; First verification data is generated based on the public key corresponding to the account blacklist and the data to be verified; second verification data is generated based on the public generator and the data to be verified; the public generator is a pre-set public parameter. The transaction request is verified based on the identity verification data, the first verification value, and the second verification value.

2. The blockchain-based verification method according to claim 1, characterized in that, Before parsing the transaction request to obtain the identity verification data carried in the transaction request, the method further includes: Based on the relationship between the transaction account and each account in the account blacklist, non-existence evidence is generated corresponding to the transaction account; wherein, the non-existence evidence indicates whether the transaction account belongs to the account blacklist. Calculate the response to the challenge based on the non-existence evidence according to the challenge response mechanism; The identity verification data is generated based on the non-existent evidence, the response, and the version information of the account blacklist.

3. The blockchain-based verification method according to claim 2, characterized in that, Based on the relationship between the transaction account and each account in the account blacklist, non-existence evidence corresponding to the transaction account is generated, including: Calculate the deviation between the account address of the transaction account and the account addresses of each account in the account blacklist; The non-existence evidence corresponding to the transaction account is calculated based on the sum of the various deviations.

4. The blockchain-based verification method according to claim 3, characterized in that, After generating non-existence evidence corresponding to the transaction account based on the relationship between the transaction account and each account in the account blacklist, the method further includes: If the sum of all deviations is a set value, then the non-existence evidence is rejected, or the non-existence evidence is set to a predetermined value.

5. The blockchain-based verification method according to claim 2, characterized in that, According to the challenge-response mechanism, the response corresponding to the challenge based on the aforementioned non-existence evidence is calculated, including: Select a random number, and calculate a commitment based on the public generator; The challenge is obtained by calculating the version information of the transaction account, the non-existence evidence, the commitment, and the account blacklist based on the preset function; Generate a response corresponding to the challenge.

6. The blockchain-based verification method according to claim 5, characterized in that, Based on the non-existent evidence, the response, and the version information of the account blacklist, the identity verification data is generated, including: The identity verification data is generated by combining the commitment, the response, the non-existence evidence, and the version information of the account blacklist.

7. The blockchain-based verification method according to claim 1, characterized in that, The identity verification data includes commitments, responses, and non-existence evidence. The commitments are generated based on random numbers, the responses are generated based on a challenge-response mechanism, and the non-existence evidence indicates whether the transaction account belongs to the account blacklist. The identity verification data is calculated according to a preset function to obtain the data to be verified, including: The commitment, the response, the non-existence evidence, and the transaction account are calculated according to a preset function to obtain the data to be verified.

8. The blockchain-based verification method according to claim 7, characterized in that, First verification data is generated based on the public key corresponding to the account blacklist and the data to be verified, including: Using the public key corresponding to the account blacklist as the base and the data to be verified as the exponent, a public key exponent is calculated; the product of the public key exponent and the commitment is used as the first verification data. Generate second verification data based on the publicly available generator and the data to be verified, including: The response is used as a power of the publicly disclosed generator to calculate the second verification data.

9. The blockchain-based verification method according to any one of claims 1-7, characterized in that, The identity verification data includes non-existence evidence and version information of the account blacklist, wherein the non-existence evidence indicates whether the transaction account belongs to the account blacklist; The transaction request is verified based on the identity verification data, the first verification value, and the second verification value, including: If the version information of the account blacklist in the identity verification data is inconsistent with the current publicly available version information of the account blacklist, the verification is determined to fail. If the version information of the account blacklist in the identity verification data is consistent with the current publicly available version information of the account blacklist, then the relationship between the non-existent evidence and the preset value is detected. If the non-existent evidence matches the preset value, the verification is deemed to have failed. If the non-existent evidence is inconsistent with the preset value, then the relationship between the first verification value and the second verification value is detected; If the first check value and the second check value are the same, the check is determined to be successful; if the first check value and the second check value are different, the check is determined to be unsuccessful.

10. An electronic device, characterized in that, include: processor; as well as Memory for storing the executable instructions of the processor; The processor is configured to execute the executable instructions to implement the blockchain-based verification method as described in any one of claims 1 to 9.

Images