Intelligent enterprise invoice management and tracing method and system based on block chain

Abstract

The invention provides an enterprise invoice intelligent management and tracing method and system based on a block chain, and relates to the field of block chains, and the method comprises the steps: carrying out the standardization and Hash chaining of invoice data, and employing zero-knowledge proof to generate a verification voucher; the data security is protected through homomorphic encryption during circulation; abnormal detection and marking in a ciphertext state are realized; and traceability is carried out based on homomorphic operation and a verifiable decryption technology. According to the invention, invoice full-life-cycle traceability management is realized, data are ensured not to be tampered, privacy is protected, and the credibility and security of invoice circulation are improved at the same time.

Description

Technical Field

[0001] This invention relates to blockchain technology, and more particularly to a blockchain-based intelligent management and traceability method and system for enterprise invoices. Background Technology

[0002] With the rapid development of the digital economy, corporate financial management has placed higher demands on the effective management and traceability of invoices. Traditional invoice management mainly relies on centralized database systems, requiring companies to establish invoice ledgers to record the flow of invoices. With the promotion and application of electronic invoices, tax authorities have built electronic invoice service platforms, through which companies can issue and verify invoices. However, in the process of invoice flow between companies, problems such as information silos, data security, and difficulty in traceability still exist.

[0003] Blockchain technology, with its immutable, decentralized, and traceable characteristics, offers a new technological path for enterprise invoice management. Currently, blockchain-based invoice management systems exist on the market, enabling authenticity verification and transaction recording of invoices by uploading invoice information to the blockchain. Simultaneously, with the development of privacy-preserving computing technologies, cryptographic tools such as zero-knowledge proofs and homomorphic encryption can achieve trusted data verification while protecting data privacy, providing security for sensitive corporate financial information.

[0004] Existing invoice-on-chain solutions often store raw invoice data directly on the blockchain, lacking effective privacy protection mechanisms. This makes sensitive financial information easily leaked, failing to meet companies' needs for trade secret protection. Relying on centralized verification agencies makes it difficult to guarantee data consistency and authenticity during invoice circulation. When invoices circulate among multiple companies, information gaps can easily occur, resulting in incomplete traceability chains. Existing invoice management systems lack real-time monitoring and verification mechanisms for abnormal circulation, making it difficult to effectively identify and collect evidence of anomalies during invoice circulation while protecting data privacy, increasing corporate financial risks and compliance costs. Summary of the Invention

[0005] This invention provides a blockchain-based intelligent management and traceability method and system for enterprise invoices, which can solve the problems in the prior art.

[0006] A first aspect of this invention provides a blockchain-based intelligent management and traceability method for enterprise invoices, comprising: Obtain invoice data and perform standardization processing to generate structured invoice data. Extract fields from the structured invoice data and concatenate them. Perform a hash operation on the concatenated result to obtain the invoice hash value. The structured invoice data is processed with zero-knowledge proof to generate verification credentials. The invoice hash value and verification credentials are submitted to the consortium blockchain network for consensus verification through a smart contract and then written into the target block to generate an on-chain identifier. When an invoice is transferred in a business transaction, the on-chain identifier is obtained based on the invoice hash value. The transfer information is then homomorphically encrypted to generate encrypted transfer data. The encrypted transfer data and the on-chain identifier are written into a new block and a relationship is established to generate a transfer identifier. The encrypted data is obtained from the new block. The state transition verification calculation is performed in the ciphertext state. When an abnormal state transition is detected, an abnormal flag is generated and written to the verification block. When a tracing request is received, the on-chain identifier and associated circulation identifier are obtained based on the invoice hash value. Homomorphic operations are performed on the encrypted circulation data to verify its integrity. Based on the verification result, verifiable decryption is performed to reconstruct the circulation path. When there is an anomaly marker in the verification block, zero-knowledge proof is performed to generate ciphertext evidence. The circulation path and ciphertext evidence are output as the tracing result.

[0007] The process involves acquiring invoice data, standardizing it to generate structured invoice data, extracting fields from the structured invoice data, concatenating them, and performing a hash operation on the concatenated result to obtain the invoice hash value, which includes: The invoice data is parsed into plaintext data blocks and encrypted data blocks. Field recognition is performed on the plaintext data blocks to obtain the plaintext field set, and the encrypted data blocks are decrypted to obtain the ciphertext field set. Calculate the cross-validation value between the plaintext field set and the ciphertext field set, confirm the valid fields based on the cross-validation value, convert the confirmed valid fields into standard fields according to a preset mapping relationship, and generate structured invoice data; Extract product information field, amount information field, invoice time field and invoice subject field from structured invoice data, calculate the time series correlation of the extracted fields to obtain the field time series chain, and combine the fields with continuous time series in the field time series chain to obtain multiple time series field groups; Based on cross-validation values, multiple time series field groups are divided into confidence levels. Within each confidence level, the time series field groups are reordered according to the field time series chain to generate a field sequence. The field sequences of different confidence levels are combined to generate a spliced ​​sequence set. Calculate the hash value for each concatenated sequence in the concatenated sequence set to obtain a hash value set, and then combine the hash values ​​in the hash value set according to the credibility level to synthesize an invoice hash value.

[0008] The structured invoice data is processed using zero-knowledge proofs to generate verification credentials. The invoice hash value and verification credentials are then submitted to the consortium blockchain network via a smart contract for consensus verification and written into the target block, generating an on-chain identifier including: Extract field information from structured invoice data, map the field information to proof elements in a homomorphic polynomial space, construct a zero-knowledge proof circuit based on the proof elements, generate attribute proof vectors and content proof vectors in the zero-knowledge proof circuit, and combine the attribute proof vectors and content proof vectors to construct a verification polynomial. Based on the verification polynomial, a knowledge extraction transformation is performed to generate a proof sequence. A mask vector is generated for the proof sequence. A bilinear mapping transformation is performed on the mask vector to generate a proof response sequence. The proof response sequence is compressed to generate a verification credential. The invoice hash value and verification certificate are packaged into transaction data, and the transaction data is submitted to the consortium blockchain network through a smart contract. In the consortium blockchain network, the verification certificate is decompressed to restore the proof response sequence. Based on the proof response sequence, bilinear pairing verification is performed to generate the verification result. The verification result is then matched with the invoice hash value using zero-knowledge matching to generate a consensus request. A consensus request is broadcast to the consortium blockchain network for consensus verification. A block write instruction is generated based on the consensus verification result. Transaction data is written to the target block based on the block write instruction. The block number and transaction sequence number are extracted from the target block and combined to generate an on-chain identifier.

[0009] When an invoice is transferred in a business transaction, an on-chain identifier is obtained based on the invoice's hash value. The transfer information is then homomorphically encrypted to generate encrypted transfer data. This encrypted transfer data and the on-chain identifier are written into a new block and associated. The generated transfer identifier includes: Extract business identification information and flow content information from the flow information, map the flow information into ciphertext elements in the homomorphic polynomial space, perform homomorphic encryption operations using the ciphertext elements to generate encrypted flow data, and construct a homomorphic proof vector based on the ciphertext elements. Based on the invoice hash value, query the target block in the consortium blockchain network, extract the on-chain identifier and block storage location information from the target block, combine the on-chain identifier with the encrypted flow data and homomorphic proof vector to generate block-related data, and calculate the integrity verification value of the block-related data. A bilinear mapping transformation is performed on the block-related data and integrity verification value to generate a dense state verification vector. The dense state verification vector is then paired with the homomorphic proof vector to generate a verification result. A verification proof sequence is then constructed based on the verification result. Zero-knowledge matching verification is performed on the verification proof sequence to generate verification status information. Based on the verification status information, a block write instruction is constructed. The block write instruction is combined with the block-associated data and integrity verification value to construct the block storage data. Broadcast block storage data to the consortium blockchain network, write encrypted transfer data and on-chain identifier into a new block and establish a relationship, extract block number and transaction sequence number from the new block to generate transfer identifier.

[0010] The process involves obtaining encrypted streaming data from a new block, performing state transition verification calculations in the ciphertext state, and generating and writing an exception flag to the verification block when a state transition anomaly is detected. Extract encrypted transfer data from the new block, perform homomorphic parsing on the encrypted transfer data to obtain the state before and after transfer, and perform homomorphic difference operation on the state before and after transfer to obtain the state change amount; Based on the state change quantity, a state transition verification equation is constructed in the encrypted state. The state change quantity is then compared with the preset business rules to calculate the homomorphic conformity, and the state transition verification calculation result is obtained. The homomorphic threshold judgment is then performed on the state transition verification calculation result to obtain the anomaly judgment result. When the anomaly determination result indicates that the state transition verification calculation result deviates from the preset compliance range, a state transition anomaly is detected. The state change quantity that caused the state transition anomaly is extracted and homomorphic hash operation is performed to obtain the anomaly feature value. An anomaly verification credential is obtained by constructing a zero-knowledge proof based on the anomaly feature value. An anomaly marker is generated based on the anomaly verification credential and the anomaly feature value. The anomaly marker is then written into the verification block through a smart contract.

[0011] Upon receiving a traceability request, the on-chain identifier and associated transfer identifier are obtained based on the invoice hash value. Homomorphic operations are then performed on the encrypted transfer data to verify its integrity, including: Receive traceability requests and extract invoice hash values ​​from them. Based on the invoice hash values, query the target block in the consortium blockchain network to obtain the on-chain identifier. Locate the new block in the consortium blockchain network based on the on-chain identifier. Extract the circulation identifier, encrypted circulation data, and integrity verification value from the new block. Perform homomorphic hashing on the encrypted data to generate the current verification value, extract the homomorphic proof vector from the new block, and perform homomorphic comparison between the current verification value and the integrity verification value to obtain the integrity matching result; The source credibility result is obtained by performing zero-knowledge matching verification between the homomorphic proof vector and the encrypted flow data. When both the integrity matching result and the source credibility result are verified as passed, an integrity verification pass identifier is generated as the verification result.

[0012] Based on the verification results, a verifiable decryption and reconstruction of the flow path is performed. When an anomaly marker exists in the verification block, zero-knowledge proof is executed to generate ciphertext evidence. The flow path and ciphertext evidence are output as the tracing results, including: Based on the integrity verification in the verification results, the verifiable decryption process is triggered by the identifier. Verifiable decryption operation is performed on the encrypted data to obtain the flow status sequence. Flow time information and flow business information are extracted from the flow status sequence. The flow time information and flow business information are sorted, assembled and reconstructed according to the time sequence relationship of the flow identifier. Based on the on-chain identifier, the verification block is retrieved in the consortium blockchain network. When an anomaly marker exists in the verification block, the anomaly feature value and anomaly verification certificate are extracted from the anomaly marker. Zero-knowledge proof verification operation is performed on the anomaly verification certificate to generate a verification validity identifier. Based on the verification validity identifier, the anomaly feature value and anomaly verification certificate are combined and encapsulated to generate encrypted evidence. The process involves combining the flow path and encrypted evidence to construct traceability data, performing digital signature operations on the traceability data to generate a traceability signature, and then encapsulating the traceability data and traceability signature as the traceability result.

[0013] A second aspect of this invention provides a blockchain-based intelligent management and traceability system for enterprise invoices, comprising: The first unit is used to acquire invoice data and perform standardized processing to generate structured invoice data. It extracts fields from the structured invoice data, concatenates them, and performs a hash operation on the concatenated result to obtain the invoice hash value. The second unit is used to perform zero-knowledge proof processing on structured invoice data to generate verification credentials. After submitting the invoice hash value and verification credentials to the consortium blockchain network for consensus verification through smart contracts, they are written into the target block to generate an on-chain identifier. The third unit is used to obtain the on-chain identifier based on the invoice hash value when an invoice is transferred, perform homomorphic encryption on the transfer information to generate encrypted transfer data, write the encrypted transfer data and the on-chain identifier into a new block and establish a relationship to generate a transfer identifier. The fourth unit is used to obtain encrypted streaming data from the new block, perform state transition verification calculations in the ciphertext state, and generate an exception flag and write it to the verification block when an exception is detected. The fifth unit is used to obtain the on-chain identifier and associated circulation identifier based on the invoice hash value when receiving a traceability request. It performs homomorphic operations on the encrypted circulation data to verify its integrity, performs verifiable decryption to reconstruct the circulation path based on the verification result, and performs zero-knowledge proof to generate ciphertext evidence when there is an anomaly marker in the verification block. It outputs the circulation path and ciphertext evidence as the traceability result.

[0014] A third aspect of the present invention provides an electronic device, comprising: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the aforementioned method.

[0015] A fourth aspect of the present invention provides a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the aforementioned method.

[0016] In this embodiment, verification credentials are generated through zero-knowledge proof processing, achieving privacy protection for invoice data while ensuring data verifiability, thus solving the problem of balancing privacy and verification in traditional invoice management. Homomorphic encryption is used to process the flow information, enabling state transition verification calculations in ciphertext mode, allowing for effective verification without decryption, significantly improving data security and processing efficiency. When an anomaly in state transition is detected, an anomaly flag is automatically generated and written into the verification block, establishing a real-time monitoring mechanism for the invoice flow process and providing an immutable chain of evidence for subsequent accountability. Homomorphic operation-based verification of the integrity of the flow data avoids the data leakage risks that may arise from traditional plaintext verification, ensuring the security of commercially sensitive information. By reconstructing the flow path through verifiable decryption and generating ciphertext evidence with zero-knowledge proofs in abnormal situations, the authenticity of the traceability results is guaranteed, while protecting the privacy of relevant parties, improving the transparency and credibility of enterprise invoice management. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating the blockchain-based intelligent management and traceability method for enterprise invoices according to an embodiment of the present invention. Figure 2 This is a flowchart of a blockchain-based privacy transfer verification method according to an embodiment of the present invention. Detailed Implementation

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

[0019] The technical solution of the present invention will be described in detail below with reference to specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0020] Figure 1 This is a flowchart illustrating the method of an embodiment of the present invention, as shown below. Figure 1 As shown, the method includes: Obtain invoice data and perform standardization processing to generate structured invoice data. Extract fields from the structured invoice data and concatenate them. Perform a hash operation on the concatenated result to obtain the invoice hash value. The structured invoice data is processed with zero-knowledge proof to generate verification credentials. The invoice hash value and verification credentials are submitted to the consortium blockchain network for consensus verification through a smart contract and then written into the target block to generate an on-chain identifier. When an invoice is transferred in a business transaction, the on-chain identifier is obtained based on the invoice hash value. The transfer information is then homomorphically encrypted to generate encrypted transfer data. The encrypted transfer data and the on-chain identifier are written into a new block and a relationship is established to generate a transfer identifier. The encrypted data is obtained from the new block. The state transition verification calculation is performed in the ciphertext state. When an abnormal state transition is detected, an abnormal flag is generated and written to the verification block. When a tracing request is received, the on-chain identifier and associated circulation identifier are obtained based on the invoice hash value. Homomorphic operations are performed on the encrypted circulation data to verify its integrity. Based on the verification result, verifiable decryption is performed to reconstruct the circulation path. When there is an anomaly marker in the verification block, zero-knowledge proof is performed to generate ciphertext evidence. The circulation path and ciphertext evidence are output as the tracing result.

[0021] In one optional implementation, invoice data is acquired and standardized to generate structured invoice data. Fields are extracted from the structured invoice data and concatenated. The concatenated result is then hashed to obtain the invoice hash value, including: The invoice data is parsed into plaintext data blocks and encrypted data blocks. Field recognition is performed on the plaintext data blocks to obtain the plaintext field set, and the encrypted data blocks are decrypted to obtain the ciphertext field set. Calculate the cross-validation value between the plaintext field set and the ciphertext field set, confirm the valid fields based on the cross-validation value, convert the confirmed valid fields into standard fields according to a preset mapping relationship, and generate structured invoice data; Extract product information field, amount information field, invoice time field and invoice subject field from structured invoice data, calculate the time series correlation of the extracted fields to obtain the field time series chain, and combine the fields with continuous time series in the field time series chain to obtain multiple time series field groups; Based on cross-validation values, multiple time series field groups are divided into confidence levels. Within each confidence level, the time series field groups are reordered according to the field time series chain to generate a field sequence. The field sequences of different confidence levels are combined to generate a spliced ​​sequence set. Calculate the hash value for each concatenated sequence in the concatenated sequence set to obtain a hash value set, and then combine the hash values ​​in the hash value set according to the credibility level to synthesize an invoice hash value.

[0022] After obtaining the invoice data, it is first parsed into plaintext data blocks and encrypted data blocks. Plaintext data blocks typically contain basic information such as the invoice code, invoice number, and invoice date, which can be directly extracted from the invoice text or image. Encrypted data blocks typically contain sensitive information that has been encrypted, such as the taxpayer identification number and commodity code.

[0023] When performing field recognition on plaintext data blocks, a pattern matching algorithm is used to scan the data and extract field information that conforms to preset rules. For example, invoice numbers are usually 8 digits, and the invoice date is in the format of "year-month-day". Through these preset rules, fields such as invoice number, invoice date, and seller name can be identified from plaintext data, forming a set of plaintext fields.

[0024] When decrypting encrypted data blocks, a key provided by the invoice system is used. The decryption process employs a symmetric encryption algorithm, such as AES or DES, to convert the encrypted data into readable field information. The decrypted fields include detailed product information, tax rate, tax amount, etc., which together form the ciphertext field set.

[0025] When calculating the cross-validation value between the plaintext and ciphertext field sets, fields common to both sets are selected, such as invoice amount and tax amount, and their values ​​are compared for consistency. Cross-validation uses a field matching degree calculation method, assigning weights to each matching field and calculating a weighted matching degree as the cross-validation value. For example, the invoice amount has a matching weight of 0.5, the tax amount has a matching weight of 0.3, and the invoice date has a matching weight of 0.2; the combined weights yield the cross-validation value.

[0026] When verifying valid fields based on cross-validation values, a threshold is set to determine field validity. Fields with cross-validation values ​​higher than the threshold are considered valid. Valid fields are then converted to standard field formats according to a predefined field mapping relationship. This predefined mapping relationship defines the correspondence between various invoice fields and standard fields; for example, "total price and tax" is mapped to "totalAmount," and "invoice date" is mapped to "issueDate." This conversion generates structured invoice data with a unified structure.

[0027] Preparation before hash calculation of key fields extracted from structured invoice data. The extracted fields include: product information fields (product name, specifications, unit price, quantity), amount information fields (amount excluding tax, tax amount, total price including tax), invoice date fields (invoice date, invoice time), and invoice entity fields (seller name, buyer name).

[0028] When calculating the temporal relevance of the extracted fields, the logical order relationship between the fields is analyzed. For example, product information comes first, followed by amount information; unit price and quantity come first, followed by amount. Based on these logical relationships, a field temporal chain is constructed to reflect the sequential dependencies between fields.

[0029] When combining fields with consecutive temporal sequences in a field time-series chain, identify fields that are temporally adjacent and logically related, and group them into time-series field groups. For example, combine "product name", "specification model", "unit price", and "quantity" into a product information time-series field group; combine "amount excluding tax", "tax amount", and "total price including tax" into an amount information time-series field group.

[0030] When classifying the confidence level of multiple time series field groups based on cross-validation values, multiple confidence thresholds are set to divide the time series field groups into three confidence levels: high, medium, and low. Cross-validation values ​​above 0.8 are considered high confidence, between 0.5 and 0.8 are considered medium confidence, and below 0.5 are considered low confidence.

[0031] Within each confidence level, the time-series field groups are reordered according to the field time-series chain to generate an ordered field sequence. Field sequences at high confidence levels are placed first, followed by those at medium confidence levels, and finally those at low confidence levels, forming a complete set of concatenated sequences.

[0032] The SHA-256 hash algorithm is used to calculate the hash value for each concatenated sequence in the set of concatenated sequences. Field values ​​are concatenated into a string, spaces and special characters are removed, and then the hash value is calculated. Multiple hash values ​​are calculated for concatenated sequences with different confidence levels, forming a hash value set.

[0033] The hash values ​​in the hash value set are weighted according to their credibility level to synthesize the final invoice hash value. High-credibility hash values ​​have a weight of 0.6, medium-credibility hash values ​​have a weight of 0.3, and low-credibility hash values ​​have a weight of 0.1. Different hash values ​​are combined into a unique invoice hash value through weighted averaging or bitwise operations.

[0034] In practical applications, when processing VAT invoices, plaintext data blocks may contain information such as invoice code, invoice number, and invoice date, while encrypted data blocks contain encrypted product details and tax information. During parsing, OCR technology is used to extract plaintext information from the invoice image, and the encrypted data is decrypted using a key. Cross-validation compares the amount in the plaintext with the decrypted amount to ensure data integrity. The resulting hash value can be used for invoice authenticity verification and data traceability, providing technical support for corporate financial management and tax compliance.

[0035] In one optional implementation, zero-knowledge proof processing is performed on the structured invoice data to generate a verification credential. The invoice hash value and verification credential are then submitted to the consortium blockchain network for consensus verification via a smart contract and written into the target block, generating an on-chain identifier including: Extract field information from structured invoice data, map the field information to proof elements in a homomorphic polynomial space, construct a zero-knowledge proof circuit based on the proof elements, generate attribute proof vectors and content proof vectors in the zero-knowledge proof circuit, and combine the attribute proof vectors and content proof vectors to construct a verification polynomial. Based on the verification polynomial, a knowledge extraction transformation is performed to generate a proof sequence. A mask vector is generated for the proof sequence. A bilinear mapping transformation is performed on the mask vector to generate a proof response sequence. The proof response sequence is compressed to generate a verification credential. The invoice hash value and verification certificate are packaged into transaction data, and the transaction data is submitted to the consortium blockchain network through a smart contract. In the consortium blockchain network, the verification certificate is decompressed to restore the proof response sequence. Based on the proof response sequence, bilinear pairing verification is performed to generate the verification result. The verification result is then matched with the invoice hash value using zero-knowledge matching to generate a consensus request. A consensus request is broadcast to the consortium blockchain network for consensus verification. A block write instruction is generated based on the consensus verification result. Transaction data is written to the target block based on the block write instruction. The block number and transaction sequence number are extracted from the target block and combined to generate an on-chain identifier.

[0036] For structured invoice data obtained from a company's financial system, core fields are extracted, including invoice code, invoice number, invoice date, buyer's name, seller's name, product name, unit price, quantity, and total amount. These fields are then converted into proof elements in a homomorphic polynomial space using a homomorphic mapping function. The homomorphic mapping function employs elliptic curve cryptography, mapping string or numeric fields to points on a curve. Specifically, for string fields, their hash value is calculated first, and then mapped onto an elliptic curve; for numeric fields, they are directly converted into elements in a finite field before being mapped onto the curve. The mapping function is defined as f(x) = g x mod p, where g is the generator and p is a large prime number. Taking the invoice number "1234567890" as an example, its SHA-256 hash value is calculated to obtain a 32-byte digest. The digest is divided into eight 32-bit integers, and each integer is mapped to a point on an elliptic curve to form a sequence of proof elements.

[0037] A zero-knowledge proof circuit is constructed based on the generated proof elements. The circuit consists of a constraint system and a polynomial expression. In the proof circuit, invoice attribute information (such as invoice type, invoice date, tax rate, etc.) is encoded as an attribute proof vector *a*, and invoice content information (such as product information, amount, etc.) is encoded as a content proof vector *b*. Both the attribute and content proof vectors are encrypted using the Pedersen commitment scheme to ensure that the original data is not leaked. The two vectors are combined through polynomial interpolation to construct a verification polynomial P(x), which satisfies the constraint ∑ai·bi = c, where c is a constant term. The verification polynomial construction process uses Lagrange interpolation to ensure that the polynomial value at a specific evaluation point is equal to the value of the proof element.

[0038] During the knowledge extraction transformation, the verification polynomial P(x) is randomly sampled, and a random point r is selected on the elliptic curve to calculate P(r) and generate a proof sequence. The proof sequence consists of polynomial values ​​at multiple evaluation points, denoted as {P(r1), P(r2), ..., P(rn)}. To improve security, a mask vector m is generated for the proof sequence. The elements in the mask vector are generated by a random number generator. The mask vector is used to obfuscate the proof sequence, generating an obfuscated sequence {P(r1)·m1, P(r2)·m2, ..., P(rn)·mn}. Subsequently, a bilinear mapping transformation is performed, using the pairing function e: G1×G2→GT to map the obfuscated sequence to the target group GT, generating the proof response sequence {e(P(r1)·m1, g), e(P(r2)·m2, g), ..., e(P(rn)·mn, g)}, where g is a generator in group G2. The verification voucher is generated by compressing the response sequence using the Merkle tree compression algorithm. The size of the verification voucher is usually several hundred bytes, which is much smaller than the original invoice data.

[0039] The original invoice data is processed using the SHA-256 algorithm to calculate the invoice hash value h. The invoice hash value h and the verification credential vc are then packaged into transaction data tx={h, vc}. The transaction data is submitted via a smart contract `submit_invoice(h, vc)` pre-deployed on the consortium blockchain. The smart contract implements the transaction verification logic, including invoice format verification, hash value verification, and zero-knowledge proof verification. The smart contract executes in a blockchain virtual machine environment, supporting Turing-complete computing power.

[0040] After receiving transaction data, the validator nodes in the consortium blockchain network first decompress the validator credential vc and restore the proof response sequence {e(P(r1)·m1, g), e(P(r2)·m2, g), ..., e(P(rn)·mn, g)}. Based on the proof response sequence, bilinear pairing verification is performed, using the bilinear pairing equation e(P(r)·m, g) = e(P(r), g) m The validity of the proof response sequence is checked. If the pairing verification passes, the verification result is compared with the invoice hash value using a zero-knowledge matching verification method. The matching verification checks whether the hash value is consistent with the commitment in the zero-knowledge proof. After successful verification, a consensus request req={tx, verify_result} is generated.

[0041] The consortium blockchain network uses an improved PBFT consensus algorithm to handle consensus requests. Verifying nodes broadcast the consensus request to other nodes in the network; these nodes repeat the verification process and return the verification result. Consensus is considered achieved when more than two-thirds of the nodes pass verification. After consensus verification is complete, a block write instruction `write_block(tx, block_number)` is generated to write the transaction data to the target block. After the target block is generated, the block number `bn` and transaction sequence number `tn` are extracted and combined to generate the on-chain identifier `chain_id = bn + "-" + tn`. This on-chain identifier serves as a unique index for the invoice on the blockchain and is used for subsequent invoice queries and verifications.

[0042] In this embodiment, zero-knowledge proof technology protects the privacy and security of enterprise invoice data while ensuring its authenticity and integrity. The zero-knowledge proof mechanism based on homomorphic encryption allows for data validity verification without disclosing the original invoice data, solving the privacy protection problem in traditional invoice management. The use of consortium blockchain technology achieves tamper-proof storage and full-process traceability of invoice data, improving the transparency and credibility of invoice management. The combination of zero-knowledge proof and blockchain technology satisfies regulatory requirements while protecting enterprise trade secrets, effectively balancing the conflict between information sharing and privacy protection.

[0043] like Figure 2 The diagram shows a flowchart of the privacy transfer verification method based on blockchain in this embodiment.

[0044] In one optional implementation, when an invoice undergoes business processing, an on-chain identifier is obtained based on the invoice hash value. Homomorphic encryption is then applied to the processing information to generate encrypted processing data. This encrypted processing data and the on-chain identifier are written into a new block and associated. Generating the processing identifier includes: Extract business identification information and flow content information from the flow information, map the flow information into ciphertext elements in the homomorphic polynomial space, perform homomorphic encryption operations using the ciphertext elements to generate encrypted flow data, and construct a homomorphic proof vector based on the ciphertext elements. Based on the invoice hash value, query the target block in the consortium blockchain network, extract the on-chain identifier and block storage location information from the target block, combine the on-chain identifier with the encrypted flow data and homomorphic proof vector to generate block-related data, and calculate the integrity verification value of the block-related data. A bilinear mapping transformation is performed on the block-related data and integrity verification value to generate a dense state verification vector. The dense state verification vector is then paired with the homomorphic proof vector to generate a verification result. A verification proof sequence is then constructed based on the verification result. Zero-knowledge matching verification is performed on the verification proof sequence to generate verification status information. Based on the verification status information, a block write instruction is constructed. The block write instruction is combined with the block-associated data and integrity verification value to construct the block storage data. Broadcast block storage data to the consortium blockchain network, write encrypted transfer data and on-chain identifier into a new block and establish a relationship, extract block number and transaction sequence number from the new block to generate transfer identifier.

[0045] During the invoice processing flow, the first step is to obtain the invoice information that needs to be transferred, including the invoice hash value, invoice transferor information, and other relevant data. The invoice hash value is a fixed-length string calculated from the invoice data using hash algorithms such as SHA-256, used to uniquely identify the invoice.

[0046] When an invoice is transferred in a business transaction, it is necessary to extract business identification information and transfer content information from the transfer information. Business identification information includes the identity of the transferring party, transfer timestamp, transfer type, etc.; transfer content information includes sensitive data such as transfer amount, product details, and tax information. To protect this sensitive information, homomorphic encryption technology is used to encrypt the transfer information.

[0047] Specifically, the extracted flow information is mapped to ciphertext elements in a homomorphic polynomial space. Taking Paillier homomorphic encryption as an example, two large prime numbers p and q are chosen, and n = p × q is calculated as part of the public key, and λ = lcm(p-1, q-1) is calculated as the private key. The flow information m is mapped to the Zn space, and then a random number r ∈ Zn* is chosen to calculate the ciphertext c = (1 + n). m ·r n mod n 2 This ciphertext element supports the additive homomorphic property, meaning that the product of two ciphertexts, when decrypted, equals the sum of their corresponding plaintexts.

[0048] Based on the generated ciphertext elements, a homomorphic proof vector V is constructed. This vector contains a zero-knowledge proof of the ciphertext's validity, demonstrating that the encryption operation was executed correctly without revealing the original data. The homomorphic proof vector typically contains ciphertext elements, a random challenge value, and the corresponding response value, used for subsequent verification.

[0049] The target block is queried in the consortium blockchain network based on the invoice hash value. During the query process, the blockchain node retrieves the Merkle root in the block header using the invoice hash value, and then locates the block containing the invoice information by following the Merkle path. The on-chain identifier (including block height, transaction index, etc.) and block storage location information are extracted from the target block.

[0050] The on-chain identifier, encrypted flow data, and homomorphic proof vector are combined in blocks to generate block-related data. Specifically, the on-chain identifier is placed at the beginning of the block-related data, followed by the encrypted flow data, and finally the homomorphic proof vector, forming a complete related data structure. An integrity check value is calculated for the block-related data, using the Keccak-256 hash function to generate a 32-byte check value to ensure data integrity.

[0051] A bilinear mapping transformation is performed on the block association data and integrity check values ​​to generate a dense-state verification vector. A bilinear mapping is a mapping function e between two groups: G1×G2→GT, satisfying e(aP, bQ)=e(P,Q). (ab) The properties of are given, where P∈G1, Q∈G2, and a, b are scalars. This mapping maps block-related data onto elliptic curve points, constructing a dense-state verification vector.

[0052] A bilinear pairing operation is performed between the encrypted verification vector and the homomorphic proof vector to generate a verification result. This bilinear pairing operation verifies the correctness of encrypted data without decryption, ensuring data privacy while guaranteeing the verifiability of the transmitted information. Based on the verification result, a verification proof sequence containing multiple verification step states is constructed.

[0053] Zero-knowledge matching verification is performed on the verification proof sequence to generate verification status information. Zero-knowledge verification allows verification nodes in the blockchain network to confirm the legitimacy of the flowing information without obtaining the original data content. After successful verification, a block write instruction is constructed based on the verification status information. This instruction includes information such as transaction type and data storage location.

[0054] The block write command, along with the block association data and integrity verification value, is combined to construct the complete block storage data, which is then broadcast to the consortium blockchain network. Upon receiving the broadcast data, the consensus nodes in the blockchain network execute a consensus algorithm (such as PBFT or Raft) to verify the transaction validity. After reaching a consensus, they write the encrypted transaction data and the on-chain identifier into a new block and establish the association.

[0055] After a new block is generated, the block number and transaction sequence number are extracted and combined to generate a transfer identifier. The transfer identifier uses the format "block number: transaction sequence number", for example, "10086:42" represents the 42nd transaction in block with block height 10086. This transfer identifier serves as the unique proof of the invoice in this transfer and can be used for subsequent tracking and query operations.

[0056] The above technical solutions achieve privacy protection and reliable storage of invoice circulation information, ensuring the confidentiality, integrity and immutability of data during the invoice circulation process, and providing safe and reliable technical support for electronic invoice management.

[0057] In one optional implementation, the process of obtaining encrypted streaming data from a new block, performing state transition verification calculations in the ciphertext state, and generating an exception flag and writing it into the verification block when an anomaly is detected includes: Extract encrypted transfer data from the new block, perform homomorphic parsing on the encrypted transfer data to obtain the state before and after transfer, and perform homomorphic difference operation on the state before and after transfer to obtain the state change amount; Based on the state change quantity, a state transition verification equation is constructed in the encrypted state. The state change quantity is then compared with the preset business rules to calculate the homomorphic conformity, and the state transition verification calculation result is obtained. The homomorphic threshold judgment is then performed on the state transition verification calculation result to obtain the anomaly judgment result. When the anomaly determination result indicates that the state transition verification calculation result deviates from the preset compliance range, a state transition anomaly is detected. The state change quantity that caused the state transition anomaly is extracted and homomorphic hash operation is performed to obtain the anomaly feature value. An anomaly verification credential is obtained by constructing a zero-knowledge proof based on the anomaly feature value. An anomaly marker is generated based on the anomaly verification credential and the anomaly feature value. The anomaly marker is then written into the verification block through a smart contract.

[0058] Extracting encrypted transfer data from new blocks is the starting point for anomaly detection. Specifically, blockchain nodes monitor the generation of new blocks. Once a new block is confirmed, the block header is decrypted using a preset private key to obtain the data index information. Based on this index information, the encrypted transfer data is located and extracted from the block body. This encrypted transfer data is typically stored using homomorphic encryption, maintaining data privacy while allowing ciphertext computation. A homomorphic parsing operation is then performed on the extracted encrypted transfer data, decomposing it into its pre-transfer ciphertext E(S). before ) and the ciphertext E(S) after the transfer afterFor example, in an asset transaction scenario, the pre-transfer state might represent the amount of assets owned by account A, and the post-transfer state might represent the amount of assets held by account A after the transaction. Then, utilizing the properties of homomorphic encryption, a homomorphic difference operation is performed on the pre-transfer and post-transfer states: E(ΔS) = E(S) after ) - E(S before We obtain the encrypted representation of the state change, E(ΔS), which represents the actual effect of the state transition.

[0059] Based on the acquired state change quantities, a state transition verification equation is constructed in the ciphertext state. First, a set of rules applicable to the current business scenario is extracted from a pre-defined rule base. These rules are stored in ciphertext form, denoted as E(Rules). Rules may include constraints such as transaction amount limits and transaction frequency restrictions. Next, homomorphic compliance calculation is performed: E(C) = HomoCompute(E(ΔS), E(Rules)), where HomoCompute represents a function that calculates the compliance between the state change quantities and the rules in the ciphertext domain. For example, in a fund transfer scenario, the rule may require that a single transaction does not exceed a specific threshold; homomorphic comparison can be used to check whether the state change quantities comply with this rule. The calculated E(C) is the ciphertext result of the state transition verification. Homomorphic threshold determination is then performed on E(C): E(Result) = HomoThreshold(E(C), E(T)), where E(T) is the encrypted threshold parameter. HomoThreshold determines whether the calculated result exceeds the threshold in the ciphertext state. After the operation is completed, the encrypted anomaly determination result E(Result) is obtained.

[0060] When the anomaly assessment result indicates that the state transition verification result deviates from the preset compliance range, the anomaly handling process is triggered. First, key information is extracted from the encrypted anomaly assessment result E(Result) to locate the specific state change E(ΔS) that caused the anomaly. a Perform a homomorphic hash operation on the abnormal state change: E(H) = HomoHash(E(ΔS)) aThe process begins by obtaining the encrypted form of the anomalous feature value, E(H). A homomorphic hash function ensures that a unique feature value is generated in the ciphertext state without decrypting the original data. Next, a zero-knowledge proof is constructed based on the anomalous feature value to generate verifiable proof data that does not reveal the original information. Specifically, the zk-SNARK protocol is used to generate proof pairs (π, vk), where π is the proof itself and vk is the verification key. During the proof process, a private input E(ΔS_abnormal) and a public input E(H) are used to generate a zero-knowledge proof that proves "the amount of state change that causes the feature value E(H) is known," but without revealing the actual content of the state change. Finally, the anomalous feature value E(H) and the zero-knowledge proof π are combined to construct an anomalous tag, Tag = Combine(E(H), π), and prepared to be written to the blockchain.

[0061] When writing an anomaly tag, the tag is submitted to the blockchain network by calling the pre-defined smart contract function `recordAbnormalTag(Tag)`. The smart contract first verifies the submitter's identity and permissions, then verifies the validity of the zero-knowledge proof to confirm the authenticity of the anomaly tag. After successful verification, the smart contract writes the anomaly tag into a specific verification block structure, simultaneously recording the timestamp and relevant block reference information, forming a complete audit chain for the anomaly event. This approach ensures both the traceability of anomaly information and protects the privacy of the original transaction data.

[0062] Through the above process, anomaly detection of state transitions on the blockchain is achieved while protecting data privacy, providing a solution for blockchain systems that balances privacy protection and security auditing.

[0063] In one optional implementation, upon receiving a traceability request, the on-chain identifier and associated transfer identifier are obtained based on the invoice hash value, and homomorphic operations are performed on the encrypted transfer data to verify its integrity, including: Receive traceability requests and extract invoice hash values ​​from them. Based on the invoice hash values, query the target block in the consortium blockchain network to obtain the on-chain identifier. Locate the new block in the consortium blockchain network based on the on-chain identifier. Extract the circulation identifier, encrypted circulation data, and integrity verification value from the new block. Perform homomorphic hashing on the encrypted data to generate the current verification value, extract the homomorphic proof vector from the new block, and perform homomorphic comparison between the current verification value and the integrity verification value to obtain the integrity matching result; The source credibility result is obtained by performing zero-knowledge matching verification between the homomorphic proof vector and the encrypted flow data. When both the integrity matching result and the source credibility result are verified as passed, an integrity verification pass identifier is generated as the verification result.

[0064] In a blockchain-based invoice traceability system, a traceability verification method based on homomorphic encryption and zero-knowledge proofs is designed to ensure the integrity and reliability of invoice data. This method achieves reliable verification of the invoice circulation process by associating on-chain identifiers and circulation identifiers.

[0065] When a user initiates a traceability request, the system first receives and parses the request, extracting the invoice hash value. The invoice hash value is a unique identifier generated from invoice data using a hash algorithm, typically SHA-256. The extracted invoice hash value is then used as the query keyword to search within the consortium blockchain network. This consortium blockchain is jointly maintained by multiple trusted institutions to ensure data tamper-proofing and traceability.

[0066] When locating a target block in the blockchain network using the invoice hash value, a distributed hash table indexing technique is employed to improve query efficiency. An on-chain identifier is extracted from the target block. This identifier typically contains information such as a timestamp, block height, and transaction index, used to uniquely locate the invoice's on-chain position. The on-chain identifier can be represented as a string like "blockHeight: txIndex: outputIndex", precisely pointing to the data location on the blockchain.

[0067] After obtaining the on-chain identifier, a new block is located in the consortium blockchain network. The new block stores the subsequent circulation information of the invoice, including the circulation identifier, encrypted circulation data, and integrity verification value. The circulation identifier is a unique identifier generated during the circulation process of the invoice, used to associate invoice data at different stages; the encrypted circulation data is the invoice circulation record processed with homomorphic encryption to ensure data privacy; and the integrity verification value is a verification credential generated through homomorphic hashing.

[0068] A homomorphic hash operation is performed on the extracted encrypted data to generate the current verification value. Homomorphic hashing leverages the properties of homomorphic encryption, allowing hash calculations to be performed in ciphertext without decrypting the original data. Specifically, an elliptic curve-based homomorphic hashing algorithm is used to process the encrypted data. This algorithm ensures data integrity verification without revealing the original data.

[0069] A homomorphic proof vector is extracted from the new block. This vector contains a series of homomorphic proof parameters used to verify the source credibility of the encrypted data flow. A homomorphic comparison operation is then performed between the current checksum and the integrity checksum extracted from the block to obtain the integrity matching result. Based on the properties of homomorphic encryption, the homomorphic comparison operation can be performed within the encrypted domain, and the output is a Boolean value indicating whether the two values ​​match.

[0070] The source trustworthiness result is obtained by performing zero-knowledge matching verification between the homomorphic proof vector and the encrypted data. Zero-knowledge matching verification uses the Schnorr protocol, allowing the verifier to confirm that the data provider knows certain secret information (such as a private key) without needing to know the secret itself. The specific process includes: the prover generates a commitment value and sends it to the verifier; the verifier returns a random challenge value; the prover calculates the response value and sends it to the verifier; the verifier verifies the correctness of the response value using a specific algorithm.

[0071] When both the integrity matching result and the source credibility result pass verification, the system generates an integrity verification pass identifier as the final verification result. This identifier typically includes a verification timestamp, a verification status code, and a digital signature to ensure the reliability of the verification result. The verification result can be returned to the user or stored on the blockchain as proof of invoice traceability.

[0072] In practical applications, such as in the context of electronic invoice circulation, when a company applies for a tax refund, the tax authorities can use this method to verify the authenticity and integrity of the invoice. The company submits a traceability request containing the invoice's hash value, the system executes the verification process described above, and the tax authorities decide whether to approve the tax refund application based on the verification results, effectively preventing fake invoices and tampering.

[0073] The above methods, by combining homomorphic encryption and zero-knowledge proof technology, not only ensure the privacy protection of invoice data during the verification process, but also achieve reliable verification of data integrity, providing a safe and efficient technical solution for blockchain invoice traceability.

[0074] In one optional implementation, a verifiable decryption and reconstruction of the flow path is performed based on the verification result. When an anomaly marker exists in the verification block, zero-knowledge proof is performed to generate ciphertext evidence. The flow path and ciphertext evidence are output as the tracing result, including: Based on the integrity verification in the verification results, the verifiable decryption process is triggered by the identifier. Verifiable decryption operation is performed on the encrypted data to obtain the flow status sequence. Flow time information and flow business information are extracted from the flow status sequence. The flow time information and flow business information are sorted, assembled and reconstructed according to the time sequence relationship of the flow identifier. Based on the on-chain identifier, the verification block is retrieved in the consortium blockchain network. When an anomaly marker exists in the verification block, the anomaly feature value and anomaly verification certificate are extracted from the anomaly marker. Zero-knowledge proof verification operation is performed on the anomaly verification certificate to generate a verification validity identifier. Based on the verification validity identifier, the anomaly feature value and anomaly verification certificate are combined and encapsulated to generate encrypted evidence. The process involves combining the flow path and encrypted evidence to construct traceability data, performing digital signature operations on the traceability data to generate a traceability signature, and then encapsulating the traceability data and traceability signature as the traceability result.

[0075] The system receives a verification result containing an integrity verification pass identifier, generated after verifying the data collected during the goods flow process. The integrity verification pass identifier in the verification result is a key indicator triggering the subsequent verifiable decryption process. When a valid integrity verification pass identifier is detected, the corresponding encrypted flow data is retrieved from a preset storage area. This encrypted flow data is a collection of information collected at each flow node of the goods and stored after encryption.

[0076] Verifiable decryption is performed on encrypted data using a threshold decryption algorithm within a homomorphic encryption framework. This requires collecting more than a preset threshold of key fragments to complete the decryption process. These key fragments are held by each participant in the data flow and collected through a secure channel. The collected key fragments are then combined to form a temporary decryption key. This temporary decryption key is used to perform decryption on the encrypted data, simultaneously generating a decryption certificate to prove the validity and correctness of the decryption process.

[0077] After decryption, a flow status sequence is obtained, which contains the flow information of goods at each node. From the flow status sequence, time information (such as arrival time and departure time) and flow business information (such as operation type, handler identifier, and location information) for each flow node are extracted sequentially. The flow time information is stored in a uniform time format (such as UTC format) to ensure the consistency of the time series; the flow business information is extracted according to a preset data structure, using the corresponding field values.

[0078] Based on the temporal relationships contained in the circulation identifiers, the extracted circulation time information and business information are sorted. The sorting uses timestamps as the primary criterion, and in cases where timestamps are the same, secondary sorting is performed based on the preset priority of the circulation nodes. After sorting, the sorted circulation information is assembled into structured circulation path data according to a unified data format. This data clearly shows the complete circulation trajectory of goods from the starting point to the current location.

[0079] Next, based on the on-chain identifier in the verification result, the corresponding verification block is retrieved in the consortium blockchain network. The on-chain identifier typically includes the block height and transaction index. A query request is sent through the blockchain node's API interface to obtain the complete content of the target verification block. The verification block content is then parsed to check for the presence of anomaly flag fields. Anomaly flags are special identifiers written to the blockchain during the preceding verification process when data inconsistency or tampering is detected.

[0080] When an anomaly marker is detected in the verification block, anomaly feature values ​​and anomaly verification credentials are extracted from the marker. The anomaly feature values ​​describe the type, location, and severity of the anomaly; the anomaly verification credentials contain cryptographic evidence proving the authenticity of the anomaly. A zero-knowledge proof verification operation is performed on the extracted anomaly verification credentials. This operation uses the Bulletproofs protocol to verify the validity of the credentials without revealing the original data. The verification operation outputs a verification validity flag, indicating whether the anomaly verification credentials have passed the zero-knowledge proof verification.

[0081] Based on the verification validity identifier, when the identifier value is valid, the abnormal feature value and abnormal verification credential are combined and encapsulated using a preset data encapsulation algorithm to generate encrypted evidence. The encapsulation process employs a layered encryption method to ensure the security of the evidence during transmission and storage, while retaining a verification access control mechanism, allowing authorized parties to verify the encrypted evidence in subsequent processes.

[0082] The reconstructed flow path and the generated encrypted evidence are combined to construct complete traceability data. This combination uses a predefined data structure to ensure clear relationships between the various parts of the traceability data. A digital signature operation is then performed on the constructed traceability data using the ECDSA signature algorithm and a preset private key to generate a digital signature, forming the traceability signature. This digital signature ensures the non-repudiation and integrity of the traceability results.

[0083] The traceability data and signatures are encapsulated according to a predefined format to generate the final traceability result. The encapsulation format supports multiple output formats, such as JSON structure or binary encoding, facilitating data exchange between different systems. The encapsulated traceability result can be output to the requesting party through a preset interface or stored in a designated database for subsequent queries. For example, when tracing the complete flow of a batch of food, this solution can reconstruct the complete path from farm to table from encrypted flow data. Furthermore, when issues such as abnormal temperatures during transportation are detected, corresponding encrypted evidence is generated, providing strong support for subsequent quality accountability while protecting the commercial privacy of all participating parties.

[0084] A second aspect of the present invention provides a system comprising: The first unit is used to acquire invoice data and perform standardized processing to generate structured invoice data. It extracts fields from the structured invoice data, concatenates them, and performs a hash operation on the concatenated result to obtain the invoice hash value. The second unit is used to perform zero-knowledge proof processing on structured invoice data to generate verification credentials. After submitting the invoice hash value and verification credentials to the consortium blockchain network for consensus verification through smart contracts, they are written into the target block to generate an on-chain identifier. The third unit is used to obtain the on-chain identifier based on the invoice hash value when an invoice is transferred, perform homomorphic encryption on the transfer information to generate encrypted transfer data, write the encrypted transfer data and the on-chain identifier into a new block and establish a relationship to generate a transfer identifier. The fourth unit is used to obtain encrypted streaming data from the new block, perform state transition verification calculations in the ciphertext state, and generate an exception flag and write it to the verification block when an exception is detected. The fifth unit is used to obtain the on-chain identifier and associated circulation identifier based on the invoice hash value when receiving a traceability request. It performs homomorphic operations on the encrypted circulation data to verify its integrity, performs verifiable decryption to reconstruct the circulation path based on the verification result, and performs zero-knowledge proof to generate ciphertext evidence when there is an anomaly marker in the verification block. It outputs the circulation path and ciphertext evidence as the traceability result.

[0085] A third aspect of the present invention provides an electronic device, comprising: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the aforementioned method.

[0086] A fourth aspect of the present invention provides a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the aforementioned method.

[0087] This invention can be a method, apparatus, system, and / or computer program product. The computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for performing various aspects of the invention.

[0088] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A blockchain-based intelligent management and traceability method for enterprise invoices, characterized in that: include: Obtain invoice data and perform standardization processing to generate structured invoice data. Extract fields from the structured invoice data and concatenate them. Perform a hash operation on the concatenated result to obtain the invoice hash value. The structured invoice data is processed with zero-knowledge proof to generate verification credentials. The invoice hash value and verification credentials are submitted to the consortium blockchain network for consensus verification through a smart contract and then written into the target block to generate an on-chain identifier. When an invoice is transferred in a business transaction, the on-chain identifier is obtained based on the invoice hash value. The transfer information is then homomorphically encrypted to generate encrypted transfer data. The encrypted transfer data and the on-chain identifier are written into a new block and a relationship is established to generate a transfer identifier. The encrypted data is obtained from the new block. The state transition verification calculation is performed in the ciphertext state. When an abnormal state transition is detected, an abnormal flag is generated and written to the verification block. When a tracing request is received, the on-chain identifier and associated circulation identifier are obtained based on the invoice hash value. Homomorphic operations are performed on the encrypted circulation data to verify its integrity. Based on the verification result, verifiable decryption is performed to reconstruct the circulation path. When there is an anomaly marker in the verification block, zero-knowledge proof is performed to generate ciphertext evidence. The circulation path and ciphertext evidence are output as the tracing result.

2. The method according to claim 1, characterized in that, The process involves acquiring invoice data, standardizing it to generate structured invoice data, extracting fields from the structured invoice data, concatenating them, and performing a hash operation on the concatenated result to obtain the invoice hash value, which includes: The invoice data is parsed into plaintext data blocks and encrypted data blocks. Field recognition is performed on the plaintext data blocks to obtain the plaintext field set, and the encrypted data blocks are decrypted to obtain the ciphertext field set. Calculate the cross-validation value between the plaintext field set and the ciphertext field set, confirm the valid fields based on the cross-validation value, convert the confirmed valid fields into standard fields according to a preset mapping relationship, and generate structured invoice data; Extract product information field, amount information field, invoice time field and invoice subject field from structured invoice data, calculate the time series correlation of the extracted fields to obtain the field time series chain, and combine the fields with continuous time series in the field time series chain to obtain multiple time series field groups; Based on cross-validation values, multiple time series field groups are divided into confidence levels. Within each confidence level, the time series field groups are reordered according to the field time series chain to generate a field sequence. The field sequences of different confidence levels are combined to generate a spliced ​​sequence set. Calculate the hash value for each concatenated sequence in the concatenated sequence set to obtain a hash value set, and then combine the hash values ​​in the hash value set according to the credibility level to synthesize an invoice hash value.

3. The method according to claim 1, characterized in that, The structured invoice data is processed using zero-knowledge proofs to generate verification credentials. The invoice hash value and verification credentials are then submitted to the consortium blockchain network via a smart contract for consensus verification and written into the target block, generating an on-chain identifier including: Extract field information from structured invoice data, map the field information to proof elements in a homomorphic polynomial space, construct a zero-knowledge proof circuit based on the proof elements, generate attribute proof vectors and content proof vectors in the zero-knowledge proof circuit, and combine the attribute proof vectors and content proof vectors to construct a verification polynomial. Based on the verification polynomial, a knowledge extraction transformation is performed to generate a proof sequence. A mask vector is generated for the proof sequence. A bilinear mapping transformation is performed on the mask vector to generate a proof response sequence. The proof response sequence is compressed to generate a verification credential. The invoice hash value and verification certificate are packaged into transaction data, and the transaction data is submitted to the consortium blockchain network through a smart contract. In the consortium blockchain network, the verification certificate is decompressed to restore the proof response sequence. Based on the proof response sequence, bilinear pairing verification is performed to generate the verification result. The verification result is then matched with the invoice hash value using zero-knowledge matching to generate a consensus request. A consensus request is broadcast to the consortium blockchain network for consensus verification. A block write instruction is generated based on the consensus verification result. Transaction data is written to the target block based on the block write instruction. The block number and transaction sequence number are extracted from the target block and combined to generate an on-chain identifier.

4. The method according to claim 1, characterized in that, When an invoice is transferred in a business transaction, an on-chain identifier is obtained based on the invoice's hash value. The transfer information is then homomorphically encrypted to generate encrypted transfer data. This encrypted transfer data and the on-chain identifier are written into a new block and associated. The generated transfer identifier includes: Extract business identification information and flow content information from the flow information, map the flow information into ciphertext elements in the homomorphic polynomial space, perform homomorphic encryption operations using the ciphertext elements to generate encrypted flow data, and construct a homomorphic proof vector based on the ciphertext elements. Based on the invoice hash value, query the target block in the consortium blockchain network, extract the on-chain identifier and block storage location information from the target block, combine the on-chain identifier with the encrypted flow data and homomorphic proof vector to generate block-related data, and calculate the integrity verification value of the block-related data. A bilinear mapping transformation is performed on the block-related data and integrity verification value to generate a dense state verification vector. The dense state verification vector is then paired with the homomorphic proof vector to generate a verification result. A verification proof sequence is then constructed based on the verification result. Zero-knowledge matching verification is performed on the verification proof sequence to generate verification status information. Based on the verification status information, a block write instruction is constructed. The block write instruction is combined with the block-associated data and integrity verification value to construct the block storage data. Broadcast block storage data to the consortium blockchain network, write encrypted transfer data and on-chain identifier into a new block and establish a relationship, extract block number and transaction sequence number from the new block to generate transfer identifier.

5. The method according to claim 1, characterized in that, The process involves obtaining encrypted streaming data from a new block, performing state transition verification calculations in the ciphertext state, and generating and writing an exception flag to the verification block when a state transition anomaly is detected. Extract encrypted transfer data from the new block, perform homomorphic parsing on the encrypted transfer data to obtain the state before and after transfer, and perform homomorphic difference operation on the state before and after transfer to obtain the state change amount; Based on the state change quantity, a state transition verification equation is constructed in the encrypted state. The state change quantity is then compared with the preset business rules to calculate the homomorphic conformity, and the state transition verification calculation result is obtained. The homomorphic threshold judgment is then performed on the state transition verification calculation result to obtain the anomaly judgment result. When the anomaly determination result indicates that the state transition verification calculation result deviates from the preset compliance range, a state transition anomaly is detected. The state change quantity that caused the state transition anomaly is extracted and homomorphic hash operation is performed to obtain the anomaly feature value. An anomaly verification credential is obtained by constructing a zero-knowledge proof based on the anomaly feature value. An anomaly marker is generated based on the anomaly verification credential and the anomaly feature value. The anomaly marker is then written into the verification block through a smart contract.

6. The method according to claim 1, characterized in that, Upon receiving a traceability request, the on-chain identifier and associated transfer identifier are obtained based on the invoice hash value. Homomorphic operations are then performed on the encrypted transfer data to verify its integrity, including: Receive traceability requests and extract invoice hash values ​​from them. Based on the invoice hash values, query the target block in the consortium blockchain network to obtain the on-chain identifier. Locate the new block in the consortium blockchain network based on the on-chain identifier. Extract the circulation identifier, encrypted circulation data, and integrity verification value from the new block. Perform homomorphic hashing on the encrypted data to generate the current verification value, extract the homomorphic proof vector from the new block, and perform homomorphic comparison between the current verification value and the integrity verification value to obtain the integrity matching result; The source credibility result is obtained by performing zero-knowledge matching verification between the homomorphic proof vector and the encrypted flow data. When both the integrity matching result and the source credibility result are verified as passed, an integrity verification pass identifier is generated as the verification result.

7. The method according to claim 1, characterized in that, Based on the verification results, a verifiable decryption and reconstruction of the flow path is performed. When an anomaly marker exists in the verification block, zero-knowledge proof is executed to generate ciphertext evidence. The flow path and ciphertext evidence are output as the tracing results, including: Based on the integrity verification in the verification results, the verifiable decryption process is triggered by the identifier. Verifiable decryption operation is performed on the encrypted data to obtain the flow status sequence. Flow time information and flow business information are extracted from the flow status sequence. The flow time information and flow business information are sorted, assembled and reconstructed according to the time sequence relationship of the flow identifier. Based on the on-chain identifier, the verification block is retrieved in the consortium blockchain network. When an anomaly marker exists in the verification block, the anomaly feature value and anomaly verification certificate are extracted from the anomaly marker. Zero-knowledge proof verification operation is performed on the anomaly verification certificate to generate a verification validity identifier. Based on the verification validity identifier, the anomaly feature value and anomaly verification certificate are combined and encapsulated to generate encrypted evidence. The process involves combining the flow path and encrypted evidence to construct traceability data, performing digital signature operations on the traceability data to generate a traceability signature, and then encapsulating the traceability data and traceability signature as the traceability result.

8. A blockchain-based intelligent management and traceability system for enterprise invoices, used to implement the method of any one of claims 1-7, characterized in that, include: The first unit is used to acquire invoice data and perform standardized processing to generate structured invoice data. It extracts fields from the structured invoice data, concatenates them, and performs a hash operation on the concatenated result to obtain the invoice hash value. The second unit is used to perform zero-knowledge proof processing on structured invoice data to generate verification credentials. After submitting the invoice hash value and verification credentials to the consortium blockchain network for consensus verification through smart contracts, they are written into the target block to generate an on-chain identifier. The third unit is used to obtain the on-chain identifier based on the invoice hash value when an invoice is transferred, perform homomorphic encryption on the transfer information to generate encrypted transfer data, write the encrypted transfer data and the on-chain identifier into a new block and establish a relationship to generate a transfer identifier. The fourth unit is used to obtain encrypted streaming data from the new block, perform state transition verification calculations in the ciphertext state, and generate an exception flag and write it to the verification block when an exception is detected. The fifth unit is used to obtain the on-chain identifier and associated circulation identifier based on the invoice hash value when receiving a traceability request. It performs homomorphic operations on the encrypted circulation data to verify its integrity, performs verifiable decryption to reconstruct the circulation path based on the verification result, and performs zero-knowledge proof to generate ciphertext evidence when there is an anomaly marker in the verification block. It outputs the circulation path and ciphertext evidence as the traceability result.

9. An electronic device, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the method described in any one of claims 1 to 7.

Images