A blockchain electronic invoice interaction method supporting three-dimensional privacy security

Abstract

The present invention discloses a blockchain electronic invoice interaction method that supports three-dimensional privacy and security. In this method, the seller first uploads the encrypted invoice file to IPFS and obtains the corresponding hash address, then the seller generates an invoice certificate, initiates a transaction and writes the certificate and the hash address into the blockchain together. Subsequently, the finance department can obtain the certificate from the blockchain to verify the authenticity of the invoice and modify the invoice reimbursement status in the blockchain. At the same time, both the purchaser and the finance department can search for the encrypted invoice file in IPFS through the hash address and obtain the original invoice through a secret sharing scheme. The present invention provides a blockchain electronic invoice that protects user privacy in all aspects, focuses on the issuance, verification and reimbursement stages of invoices, and realizes the convenience, privacy and security of electronic invoices.

Description

Technical Field

[0001] The present invention belongs to the technical field of blockchain electronic invoices, and specifically relates to a blockchain electronic invoice interaction method that supports three-dimensional privacy security. Background Art

[0002] Invoices are closely related to my country's taxation. In order to keep pace with the development of the times and realize the modernization of taxation, the State Administration of Taxation has developed an electronic invoice system for tax payers. Since the launch of the electronic invoice system, the number of electronic invoices issued in my country has increased year by year at a high growth rate. In 2022, the number of electronic invoices issued in China has reached nearly 55 billion. Electronic invoices have become an important part of my country's taxation system. However, electronic invoices are not flawless. The electronic invoice system developed based on traditional databases has some problems that cannot be ignored, including: (1) Invoices are easy to be reimbursed repeatedly; the work of invoice reimbursement is entirely undertaken by the finance department of each unit, and checking whether an invoice has been reimbursed depends entirely on the memory or record of reimbursement behavior of the finance personnel themselves. (2) Invoices are easy to be tampered with and forged; electronic invoices generally contain the signatures of the tax department and the invoice issuing company on the invoice content, but there are loopholes in the process of paperization of electronic invoices, which brings the risk of invoice tampering and forgery. (3) Personal privacy is easily leaked: Invoices usually contain private information such as transaction amount, transaction time, and the identities of sellers and buyers. The current invoice system lacks a reasonable and effective protection mechanism for user privacy. (4) The invoice system is vulnerable to attacks: The current electronic invoice data is stored in a centralized manner. Once the central server is attacked by hackers, the invoices in the database will be destroyed, and the loss is difficult to estimate.

[0003] Blockchain is a new technology that has emerged in the past decade. It is essentially a shared database and a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithm. The information stored in the blockchain is unforgeable, traceable, traceable, and open and transparent. With the continuous development of blockchain, the concept of blockchain 2.0 has gradually emerged. Smart contracts are modular, reusable, and automatically executed scripts running on blockchain. The emergence of smart contracts has greatly expanded the scope of application of blockchain.

[0004] Privacy computing is a new computing model that aims to protect users' personal privacy data while allowing data analysis and sharing. Its core idea is to perform calculations without exposing the original data. The data owner usually encrypts and anonymizes the data on the local device, and transmits the encrypted data to the computing party for calculation through security protocols and encryption algorithms, rather than sending the original data to the computing party, which greatly reduces the risk of data leakage and abuse.

[0005] Applying blockchain technology and privacy computing technology to the field of electronic invoices can effectively solve problems such as duplicate invoice reimbursement, invoice tampering and forgery, privacy leakage and vulnerability to attacks. Summary of the invention

[0006] The purpose of the present invention is to solve the technical problems existing in the electronic invoice data privacy and multi-party interaction in the prior art, and proposes a blockchain electronic invoice interaction method that supports three-dimensional privacy security.

[0007] The present invention is achieved through the following technical steps:

[0008] A blockchain electronic invoice interaction method supporting three-dimensional privacy security includes the following steps:

[0009] Step 1: The seller encrypts the original invoice file to obtain an encrypted invoice file;

[0010] Step 2: The seller uploads the encrypted invoice file to IPFS, and IPFS returns the hash address corresponding to the encrypted invoice file;

[0011] Step 3: The seller constructs a constraint circuit based on the key fields in the invoice, generates an invoice certificate using zero-knowledge proof, and uploads the invoice certificate and hash address to the blockchain;

[0012] Step 4: The purchaser or the Finance Department obtains the invoice certificate from the blockchain to verify the authenticity of the invoice; when the Finance Department reimburses the invoice, it modifies the invoice status in the blockchain;

[0013] Step 5: The purchaser or the finance department obtains the encrypted invoice file from IPFS based on the hash address, decrypts it, and obtains the invoice file in plain text.

[0014] In the above technical solution, in step 1, the algorithm for encrypting the original invoice file is as follows:

[0015] Step 1.1: The seller randomly generates a key AES and initial vector IV;

[0016] Step 1.2, the seller pads the original invoice file so that the size of the padded file is an integer multiple of the AES packet length;

[0017] Step 1.3, in CBC working mode, use key AES and IV to encrypt the invoice file;

[0018] Step 1.4: The seller obtains the RSA public key pk of the finance department of the buyer for subsequent reimbursement application through public channels. financer , and store the public keys of both parties in the specified directory;

[0019] Step 1.5, randomly generate an integer k N , k N As the slope of the straight line in the plane coordinate system, the key key AES As the vertical intercept of the straight line, we get the only straight line equation;

[0020] Step 1.6, randomly select two points N in the first quadrant of the line customer (x customer ,y customer ),N financer (x financer ,y financer ), as the secret share of the purchaser and the finance department respectively;

[0021] Step 1.7, use the RSA public key pk of the buyer and the finance department respectively customer ,pk financer For their respective secret shares N customer (x customer ,y customer ), N financer (x financer ,y financer ) to encrypt and obtain the encrypted secret share ct customer ,ct financer ; Among them, ct customer is the encrypted buyer’s secret share, ct financer A secret share of the encrypted treasury;

[0022] Step 1.8, the encrypted buyer and finance secret share ct customer ,ct financer with the initial vector IV and the slope k N Write the encrypted invoice file header to get the complete encrypted invoice file.

[0023] In the above technical solution, in step 3, the specific process of constructing the constraint circuit includes:

[0024] Step 3.1, the seller extracts the key fields in the invoice, including the invoice face value, the buyer identification number, the invoice code, the invoice number, the invoice date, the seller identification number and the verification code, and uses the invoice face value, the seller identification number, the buyer identification number and the verification code in the invoice key fields as the privacy fields;

[0025] Step 3.2, the seller constructs the constraint equation hashValue=H(Price|Customer|Nonce|invoiceNum|invoiceID|txDate|Seller) based on the key fields extracted from the invoice, where hashValue represents the checksum, Price represents the face value of the invoice, Customer represents the buyer's identification number, Nonce is a random number added to increase security, invoiceNum is the invoice code, invoiceID is the invoice number, txDate is the invoice date, and Seller is the seller's identification number; H is a hash function suitable for zero-knowledge proof. For example, taking the MiMC function as an example, its encryption function Among them, F i is the round function, F i (x) = (x + k + c i ) 3 , x is plain text, k is the key, c i is the wheel constant and is a fixed value;

[0026] Step 3.3, the seller writes a constraint circuit according to the constraint equation. In the circuit, the invoice face value Price, the buyer identification number Customer and the random number Nonce are private inputs, the invoice code invoiceNum, the invoice number invoiceID, the invoice date txDate and the seller identification number Seller are public inputs, and the check code hashValue is the output of the circuit.

[0027] In the above technical solution, in step 3, the zero-knowledge proof adopts the Groth16 algorithm.

[0028] In the above technical solution, a smart contract is deployed in the blockchain to realize the functions of invoice authenticity verification, invoice status modification and user management; the contract includes the seller's invoice creation function addInvoice(), proof addition function addProof(), authorization function giveRightToUser(), financial department designation function appointExchequer(), amount verification function verifyMoney(), and invoice verification function verifyInvoice(); among them, the addInvoice() function first determines whether the user type is the seller and whether the invoice has been issued. If the judgment is passed, the hash address hashcode corresponding to the invoice and the invoice status are written into the blockchain, and the AddInvoice event is triggered; addPro The of() function writes [A]1, [B]2, [C]1 in the corresponding proof of the invoice into the blockchain and triggers the AddProof event; the giveRightToUser() function first determines the identity of the operator and whether the target user exists. If the judgment is passed, it adds a new user and triggers the GiveRightToPerson event; the appointExchequer() function first determines whether the user exists. If the judgment is passed, it adds the user of the Finance Department; the verifyMoney() function first determines whether the invoice status is reimbursed. If not, it verifies the invoice amount. After the verification is passed, it changes the invoice status to reimbursed and triggers the VerifyMoney event; the verifyTicket() function uses the public input of the zero-knowledge proof as input to verify the corresponding proof on the blockchain.

[0029] In the above technical solution, when verifying the authenticity of an invoice, the invoice number, invoice code, invoice date, seller name and seller identification number on the invoice are entered in the invoice verification interface, and the password area field on the invoice is entered. There is no need to enter the invoice amount, buyer name, buyer identification number and other privacy fields; after clicking verify, the system verifies the input information, finds the corresponding certificate stored in the blockchain through the invoice serial number, and calls the smart contract for verification of the certificate for verification. If the invoice information is correct, the system will return verification success, otherwise it will return verification failure.

[0030] In the above technical solution, when the Finance Department reimburses an invoice, it enters its own account information, invoice number, invoice hash address and invoice amount; the system will first verify the account to determine whether the account information is that of the Finance Department; after the determination is passed, the system will call the smart contract deployed in the blockchain to verify whether the invoice is reimbursed. After the verification is passed, the authenticity of the amount will be verified. After passing, the reimbursement field of this invoice will be modified in the blockchain, and the invoice reimbursement status will be set to reimbursed. After that, this field cannot be changed again to avoid duplicate reimbursement of invoices.

[0031] In the above technical solution, in step 5, the process of decrypting the encrypted invoice file is as follows:

[0032] Step 5.1, read the auxiliary information contained in the encrypted invoice file header and obtain your own secret share ct from it customer or ct financer , as well as the initial vector IV and the slope k N ;

[0033] Step 5.2, use the buyer's RSA private key sk customer , for ct customer Decrypt to get the secret share N customer (x customer ,y customer ) or use the RSA private key sk of the Finance Department financer , for ct financer Decrypt to get the secret share N financer (x financer ,y financer );

[0034] Step 5.3, use the decrypted secret share N customer (x customer ,y customer ) or N financer (x financer ,y financer ), with slope k N Restore the equation of the line;

[0035] Step 5.4, the vertical intercept of the straight line equation is the symmetric key for decrypting the invoice AES ;

[0036] Step 5.5, use IV as the initial vector and key as key AES , decrypt the ciphertext using the AES algorithm in CBC mode;

[0037] Step 5.6, remove the padding content from the decrypted message to obtain the original invoice file.

[0038] The advantages and beneficial effects of the present invention are:

[0039] The present invention focuses on the invoice issuance, verification and reimbursement stages; in the whole process of invoice operation, user privacy is protected by a variety of security technologies, and the privacy protection of key fields of invoices is realized; the distributed storage mode of blockchain and IPFS makes the system safe and reliable in the face of network attacks; the combination of smart contracts, front-end interface and PDF extraction function brings users a more convenient user experience; the system public content can be obtained and checked by everyone, which improves the openness of the invoice process. This work can not only improve the reimbursement efficiency of electronic invoices, but also be expanded to applications such as checks and bills. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Figure 1 It is a schematic diagram of the overall process of the present invention.

[0041] Figure 2 It is a schematic diagram of the overall architecture of the present invention.

[0042] Figure 3 This is a schematic diagram of invoice file encryption.

[0043] Figure 4 It is a schematic diagram of the construction of the secret sharing scheme.

[0044] Figure 5 This is a schematic diagram of IPFS upload and download.

[0045] Figure 6 This is a schematic diagram of the zero-knowledge proof generation process.

[0046] Figure 7 This is a schematic diagram of invoice file decryption.

[0047] For ordinary technicians in this field, other relevant drawings can be obtained based on the above drawings without any creative work. DETAILED DESCRIPTION

[0048] In order to enable those skilled in the art to better understand the technical solution of the present invention, the technical solution of the present invention is further described below in conjunction with specific embodiments.

[0049] A blockchain electronic invoice interaction method supporting three-dimensional privacy security includes the following steps:

[0050] Step 1: The seller encrypts the original invoice file to obtain an encrypted invoice file.

[0051] This step corresponds to Figure 1 In process ①, the specific implementation steps of step 1 are as follows Figure 3 As shown, this step adopts a secret sharing scheme, the plane coordinate system of the secret sharing scheme is as follows Figure 4As shown. The seller completes the invoice issuance, uses the symmetric encryption algorithm AES to encrypt the invoice file, and uses the secret sharing scheme to distribute the secret share to ensure that only specific participants (including the seller and the finance department) can complete the decryption and obtain the original invoice file, while any third party cannot decrypt and obtain the original invoice file.

[0052] In this step, a (1,2) secret sharing scheme is implemented to meet the needs of both the purchaser and the finance department to obtain the original invoice file with their own keys. Subsequently, the purchaser or the finance department can use their own keys to decrypt the secret share, recover the key and decrypt the encrypted invoice to obtain the original invoice file. Figure 3 As shown, it includes the following steps:

[0053] Step 1.1, corresponding to Figure 3 In process ①, the seller randomly generates a 128-bit key AES and initial vector IV.

[0054] Step 1.2, corresponding to Figure 3 In process ②, the seller pads the original invoice file so that the size of the padded file is an integer multiple of the AES-128 packet length.

[0055] Step 1.3, corresponding to Figure 3 In process ③, in CBC working mode, use key AES and IV to encrypt the invoice file.

[0056] Step 1.4: The buyer sends his own RSA public key pk customer Provided to the seller, the seller can obtain the RSA public key pk of the finance department of the buyer for subsequent reimbursement application through public channels financer , and store the public keys of both parties in the specified directory.

[0057] Step 1.5, corresponding to Figure 3 In process ④, randomly generate an integer k N , k N As the slope of the straight line in the plane coordinate system, the key key AES As the vertical intercept of the straight line, we get the unique equation of the straight line.

[0058] Step 1.6, corresponding to Figure 3 In process ⑤, randomly select two points N in the first quadrant of the straight line. customer (x customer ,y customer ),N financer (x financer ,y financer ), as the secret shares of the purchaser and the finance department respectively, such as Figure 4 shown.

[0059] Step 1.7, corresponding to Figure 3 In process ⑥, use the RSA public key pk of the buyer and the finance department respectively customer ,pk financer For their respective secret shares N customer (x customer ,y customer ), N financer (x financer ,y financer ) to encrypt and obtain the encrypted secret share ct customer ,ct financer ; Among them, ct customer is the encrypted buyer’s secret share, ct financer A secret share of the encrypted treasury.

[0060] Step 1.8, corresponding to Figure 3 In process ⑦, the encrypted secret share ct of the buyer and the finance department is customer ,ct financer with the initial vector IV and the slope k N The auxiliary information is written into the encrypted invoice file header to obtain a complete encrypted invoice file.

[0061] Step 2: The seller uploads the encrypted invoice file to the IPFS system, and IPFS returns the hash address corresponding to the encrypted invoice file.

[0062] IPFS is a distributed file system for organizing and transmitting data, including DHT, BitTorrent, Git, and SFS, with content-based retrieval, decentralization, and peer-to-peer features. With the distributed, peer-to-peer data addressing characteristics of the IPFS system, the secure storage and convenient access of files are guaranteed. The seller uploads the encrypted invoice file to the IPFS system to ensure the secure storage and convenient access of the file. The process of uploading and downloading files on IPFS is as follows: Figure 5 As shown, the upload step corresponds to Figure 5 In the process ②, the specific method of uploading is:

[0063] Step 2.1: The seller creates an IPFS node in the local computer through the "ipfsinit" command. After initializing the node, the node's storage information is obtained, including node ID, environment configuration, data storage, etc.

[0064] Step 2.2, the seller starts the node server and uses the "ipfs daemon" command to start the node server. Once started, the current interface will be in a listening state, and a new tab needs to be created.

[0065] In step 2.3, the seller uses the "ipfs add" command to split the encrypted invoice file into blocks, and then binds the blocks together according to the tree structure to complete the file upload.

[0066] Step 2.4: After the seller completes uploading, IPFS returns the hash address hashcode of the encrypted invoice file, and the seller saves the hash address of the encrypted invoice file.

[0067] Step 3: The seller builds a constraint circuit based on the key fields in the invoice. The specific process is as follows:

[0068] Step 3.1, the seller extracts the key fields in the invoice, including the invoice face value, the buyer's identification number, the invoice code, the invoice number, the invoice date, the seller's identification number and the verification code, and sets the invoice face value, the seller's identification number, the buyer's identification number and the verification code in the invoice key fields as private fields.

[0069] Step 3.2, the seller constructs the constraint equation hashValue=MiMC(Price|Customer|Nonce|invoiceNum|invoiceID|txDate|Seller) based on the key fields extracted from the invoice, where hashValue represents the checksum, Price represents the face value of the invoice, Customer represents the buyer's identification number, Nonce is a random number added to increase security, invoiceNum is the invoice code, invoiceID is the invoice number, txDate is the invoice date, and Seller is the seller's identification number; MiMC is a hash function suitable for zero-knowledge proof (zk-Friendly), and its encryption function Among them, F i is the round function F i (x) = (x + k + c i ) 3 , x is plain text, k is the key, c i is the round constant and is a fixed value.

[0070] Step 3.3, the seller writes a constraint circuit according to the constraint equation. In the circuit, the invoice face value Price, the buyer identification number Customer and the random number Nonce are private inputs, the invoice code invoiceNum, the invoice number invoiceID, the invoice date txDate and the seller identification number Seller are public inputs, and the check code hashValue is the output of the circuit; use the circom syntax when writing the circuit, call the MultiMiMC7 module, and select the parameter as MultiMiMC7(7,91).

[0071] Step 4: The seller uses zero-knowledge proof to generate an invoice certificate based on the key fields in the invoice and the constructed constraint circuit. In this embodiment, the zero-knowledge proof uses the Groth16 algorithm to generate an invoice certificate. The specific process is as follows:

[0072] Step 4.1, corresponding to Figure 6 Follow the process ① in the figure and compile the constraint circuit using the command “circomcircuit.circom--r1cs--wasm”.

[0073] Step 4.2, corresponding to Figure 6 In process ②, perform trusted setup through the "snarkjsptn bn128 12pot12_0000.ptau", "snarkjsptc pot12_0000.ptau pot12_0001.ptau", and "snarkjs pt2 pot12_0001.ptaupot12_final.ptau" commands to generate a public reference string CRS.

[0074] Step 4.3, corresponding to Figure 6 In process ③, generate the proving key and verification key through the commands "snarkjszkn circuit.r1cs pot12_final.ptau circuit_0000.zkey", "snarkjszkc circuit_0000.zkey provingKey.zkey", and "snarkjszkevprovingKey.zkeyverificationKey.json".

[0075] Step 4.4, corresponding to Figure 6 In process ④, the witness is calculated through the “snarkjswccircuit.wasminput.jsonwitness.wtns” command.

[0076] Step 4.5, corresponding to Figure 6 In step ⑤, generate proof and public input through the command “snarkjs g16pprovingKey.zkeywitness.wtnsproof.jsonpublic.json”.

[0077] Step 4.6, generate the smart contract for verification proof through "snarkjszkesvprovingKey.zkeyverifier.sol".

[0078] In step 4.7, the generated proving key and verification key are saved in IPFS as system public parameters so that all users can obtain them.

[0079] Step 5: Deploy the smart contract in the blockchain.

[0080] The smart contract is written using Solidity version 0.6.11. The contract includes the seller's invoice creation function addInvoice(), the proof function addProof(), the authorization function giveRightToUser(), the financial department designation function appointExchequer(), the amount verification function verifyMoney(), and the invoice verification function verifyInvoice(). Among them, the addInvoice() function first determines whether the user type is the seller and whether the invoice has been issued. If the judgment is passed, the hash address hashcode corresponding to the invoice and the invoice status are written into the blockchain, and the AddInvoice event is triggered; the addProof() function writes [A]1, [B]2, [C]1 in the corresponding proof of the invoice into the blockchain, and triggers the AddProof event; the giveRightToUser() function first determines the operator identity and whether the target user exists. If the judgment is passed, a new user is added and the GiveRightToPerson event is triggered; the appointExchequer() function first determines whether the user exists. If the judgment is passed, the user of the Finance Department is added; the verifyMoney() function first determines whether the invoice status is reimbursed. If not, the invoice amount is verified. After the verification is passed, the invoice status is modified to reimbursed and the VerifyMoney event is triggered; the verifyTicket() function takes the public input of the zero-knowledge proof as input to verify the corresponding proof on the blockchain.

[0081] Step 6: The purchaser or the finance department verifies the authenticity of the invoice.

[0082] The buyer or the finance department enters the invoice number, invoice code, invoice date, seller name and seller identification number on the invoice verification interface, and enters the password field on the invoice. There is no need to enter the invoice amount, buyer name, buyer identification number and other private fields. After clicking Verify, the system verifies the input information, finds the corresponding certificate stored in the blockchain through the invoice serial number, and calls the smart contract for verification. If the invoice information is correct, the system will return a successful verification, otherwise it will return a failed verification.

[0083] Step 7: The Finance Department reimburses the invoice.

[0084] When the Finance Department reimburses an invoice, it needs to enter its own account information, invoice number, invoice hash address, and invoice amount. After clicking reimbursement, the system will first verify the account to determine whether the account information is the Finance Department. After the judgment is passed, the system will call the smart contract deployed in the blockchain to verify whether the invoice has been reimbursed. After the verification is passed, the reimbursement field of this invoice will be modified in the blockchain, and the invoice reimbursement status will be set to reimbursed. After that, this field cannot be changed again. In this way, repeated reimbursement of invoices can be avoided.

[0085] Step 8: The purchaser or the finance department uses the hash address hashcode to obtain the encrypted invoice file (i.e., encrypted invoice file) from the IPFS system.

[0086] Since the hash address hashcode of the encrypted invoice file is stored in the blockchain, and the blockchain is open and transparent, the purchaser or the finance department can obtain the hash address of the encrypted invoice file from the blockchain, and use the "ipfs cat" command to view and download the content of the specified file based on the obtained hash address, corresponding to Figure 5 The process in ③.

[0087] Step 9: The buyer or the finance department restores the secret through the secret sharing scheme and obtains the complete invoice file in plain text. The specific steps are as follows:

[0088] Step 9.1, corresponding to Figure 7 In the process ①, obtain the encrypted invoice file (i.e., the encrypted invoice file) from IPFS, read the auxiliary information contained in the header of the encrypted invoice file, and obtain your own secret share ct from it customer or ct financer , as well as the initial vector IV and the slope k N .

[0089] Step 9.2, corresponding to Figure 7 In process ②, use the buyer's RSA private key sk customer , for ct customer Decrypt to get the secret share N customer (x customer ,y customer ) or use the RSA private key sk of the Finance Department financer , for ct financer Decrypt to get the secret share N financer (x financer ,y financer ).

[0090] Step 9.3, corresponding to process ③ in 7, uses the secret share N obtained by decryption customer (xcustomer ,y customer ) or N financer (x financer ,y financer ), with slope k N Restore the equation of the line.

[0091] Step 9.4, corresponding to Figure 7 In process ④, the vertical intercept of the straight line equation is the symmetric key for decrypting the invoice. AES .

[0092] Step 9.5, corresponding to Figure 7 In process ⑤, the 128-bit IV is used as the initial vector and the key is a 128-bit key. AES , use the AES algorithm in CBC mode to decrypt the ciphertext.

[0093] Step 9.6, corresponding to Figure 7 In process ⑥, the padding content is removed from the decrypted message to obtain the original invoice file.

[0094] The present invention is described above by way of example. It should be noted that, without departing from the core of the present invention, any simple deformation, modification or other equivalent replacement that can be made by those skilled in the art without inventive effort falls within the protection scope of the present invention.

Claims

1. A blockchain electronic invoice interaction method supporting three-dimensional privacy security, characterized in that: The following steps are involved: Step 1: The seller encrypts the original invoice file to obtain an encrypted invoice file; Step 2: The seller uploads the encrypted invoice file to IPFS, and IPFS returns the hash address corresponding to the encrypted invoice file; Step 3: The seller constructs a constraint circuit based on the key fields in the invoice, generates an invoice certificate using zero-knowledge proof, and uploads the invoice certificate and hash address to the blockchain; In step 3, the specific process of building the constraint circuit includes: Step 3.1, the seller extracts the key fields in the invoice, including the invoice face value, the buyer identification number, the invoice code, the invoice number, the invoice date, the seller identification number and the verification code, and uses the invoice face value, the seller identification number, the buyer identification number and the verification code in the invoice key fields as the privacy fields; Step 3.2, the seller constructs the constraint equation hashValue=H(Price|Customer|Nonce|invoiceNum|invoiceID|txDate|Seller) based on the key fields extracted from the invoice, where hashValue represents the checksum, Price represents the face value of the invoice, Customer represents the buyer's identification number, Nonce is a random number added to increase security, invoiceNum is the invoice code, invoiceID is the invoice number, txDate is the invoice date, and Seller is the seller's identification number; H is a hash function suitable for zero-knowledge proof; Step 3.3, the seller writes a constraint circuit according to the constraint equation. In the circuit, the invoice face value Price, the buyer identification number Customer and the random number Nonce are private inputs, the invoice code invoiceNum, the invoice number invoiceID, the invoice date txDate and the seller identification number Seller are public inputs, and the check code hashValue is the output of the circuit; Step 4: The purchaser or the Finance Department obtains the invoice certificate from the blockchain to verify the authenticity of the invoice; when the Finance Department reimburses the invoice, it modifies the invoice status in the blockchain; Step 5: The purchaser or the finance department obtains the encrypted invoice file from IPFS based on the hash address, decrypts it, and obtains the invoice file in plain text.

2. The blockchain electronic invoice interaction method supporting three-dimensional privacy security according to claim 1 is characterized by: In step 1, the algorithm for encrypting the original invoice file is as follows: Step 1.1: The seller randomly generates a key AES and initial vector IV; Step 1.2, the seller pads the original invoice file so that the size of the padded file is an integer multiple of the AES packet length; Step 1.3, in CBC working mode, use key AES and IV to encrypt the invoice file; Step 1.4: The seller obtains the RSA public key pk of the finance department of the buyer for subsequent reimbursement application through public channels. financer , and store the public keys of both parties in the specified directory; Step 1.5, randomly generate an integer k N , k N As the slope of the straight line in the plane coordinate system, the key key AES As the vertical intercept of the straight line, we get the only straight line equation; Step 1.6, randomly select two points N in the first quadrant of the line customer (x customer ,y customer ),N financer (x financer ,y financer ), as the secret share of the purchaser and the finance department respectively; Step 1.7, use the RSA public key pk of the buyer and the finance department respectively customer ,pk financer For their respective secret shares N customer (x customer ,y customer ), N financer (x financer ,y financer ) to encrypt and obtain the encrypted secret share ct customer ,ct financer ; Among them, ct customer is the encrypted buyer’s secret share, ct financer A secret share of the encrypted treasury; Step 1.8, the encrypted buyer and finance secret share ct customer ,ct financer with the initial vector IV and the slope k N Write the encrypted invoice file header to get the complete encrypted invoice file.

3. The blockchain electronic invoice interaction method supporting three-dimensional privacy security according to claim 1 is characterized in that: In step 3, the zero-knowledge proof adopts the Groth16 algorithm.

4. The blockchain electronic invoice interaction method supporting three-dimensional privacy security according to claim 1 is characterized in that: Smart contracts are deployed in the blockchain to implement functions such as invoice authenticity verification, invoice status modification, and user management. The contract includes the seller's invoice creation function addInvoice(), proof addition function addProof(), authorization function giveRightToUser(), financial department designation function appointExchequer(), amount verification function verifyMoney(), and invoice verification function verifyInvoice(). The addInvoice() function first determines whether the user type is the seller and whether the invoice has been issued. If the determination is successful, the hash address hashcode corresponding to the invoice and the invoice status are written to the blockchain, and the AddInvoice event is triggered. The addProof() function The number [A]1, [B]2, [C]1 in the corresponding proof of the invoice is written into the blockchain and the AddProof event is triggered; the giveRightToUser() function first determines the identity of the operator and whether the target user exists. If the judgment is passed, a new user is added and the GiveRightToPerson event is triggered; the appointExchequer() function first determines whether the user exists. If the judgment is passed, the user of the Finance Department is added; the verifyMoney() function first determines whether the invoice status is reimbursed. If not, the invoice amount is verified. After the verification is passed, the invoice status is changed to reimbursed and the VerifyMoney event is triggered; the verifyTicket() function takes the public input of the zero-knowledge proof as input to verify the corresponding proof on the blockchain.

5. The blockchain electronic invoice interaction method supporting three-dimensional privacy security according to claim 1 is characterized in that: When verifying the authenticity of an invoice, enter the invoice number, invoice code, invoice date, seller name and seller identification number on the invoice verification interface, and enter the password area field on the invoice. There is no need to enter the invoice amount, buyer name, buyer identification number and other privacy fields; after clicking verify, the system verifies the input information, finds the corresponding certificate stored in the blockchain through the invoice serial number, and calls the smart contract for verification. If the invoice information is correct, the system will return verification success, otherwise it will return verification failure.

6. The blockchain electronic invoice interaction method supporting three-dimensional privacy security according to claim 1 is characterized in that: When the Finance Department reimburses an invoice, it enters its own account information, invoice number, invoice hash address and invoice amount; the system will first verify the account to determine whether the account information is from the Finance Department; after the determination is passed, the system will call the smart contract deployed in the blockchain to verify whether the invoice has been reimbursed. After the verification is passed, the authenticity of the amount will be verified. After passing, the reimbursement field of this invoice will be modified in the blockchain, and the invoice reimbursement status will be set to reimbursed. After that, this field cannot be changed again to avoid duplicate reimbursement of invoices.

7. The blockchain electronic invoice interaction method supporting three-dimensional privacy security according to claim 2 is characterized in that: In step 5, the process of decrypting the encrypted invoice file is as follows: Step 5.1, read the auxiliary information contained in the encrypted invoice file header and obtain your own secret share ct from it customer or ct financer , as well as the initial vector IV and the slope k N ; Step 5.2, use the buyer's RSA private key sk customer , for ct customer Decrypt to get the secret share N customer (x customer ,y customer ) or use the RSA private key sk of the Finance Department financer , for ct financer Decrypt to get the secret share N financer (x financer ,y financer ); Step 5.3, use the decrypted secret share N customer (x customer ,y customer ) or N financer (x financer ,y financer ), with slope k N Restore the equation of the line; Step 5.4, the vertical intercept of the straight line equation is the symmetric key for decrypting the invoice AES ; Step 5.5, use IV as the initial vector and key as key AES , decrypt the ciphertext using the AES algorithm in CBC mode; Step 5.6, remove the padding content from the decrypted message to obtain the original invoice file.

Images