An internet big data processing financial system

Abstract

The application relates to the technical field of internet consumption finance, and discloses an internet big data processing financial system, which comprises a business processing module, which is used for adapting multi-source heterogeneous original financial data and receiving the data, obtaining encrypted data through a symmetric encryption algorithm, and generating a storage evidence certificate package based on preset financial compliance rules; the storage evidence certificate comprises a first hash value, zero-knowledge proof and a storage address, the first hash value is obtained by performing SHA-256 operation on original data, and the zero-knowledge proof is generated by a zero-knowledge proof generating unit in the zero-knowledge proof. The internet big data processing financial system combines the permissioned blockchain of the high-speed consensus storage evidence layer with the mature public chain of the trusted anchoring layer through hierarchical blockchain architecture design, realizes second-level consensus and tens of thousands of transaction processing capabilities per second by means of an aBFT consensus algorithm, completely changes the current situation that the low TPS of the public chain cannot meet the demand of high-frequency financial transactions, and effectively meets the safety and compliance requirements of multiple scenes.

Description

Technical Field

[0001] This invention relates to the field of internet consumer finance technology, and in particular to an internet big data processing financial system. Background Technology

[0002] With the rapid development of internet technology and the arrival of the big data era, the scale and complexity of financial data are growing exponentially. Modern financial systems face multiple challenges, including massive data processing, real-time transaction verification, privacy protection, and compliance auditing. While traditional centralized financial systems have advantages in processing efficiency, they suffer from inherent flaws such as single points of failure, susceptibility to data tampering, and difficulties in audit traceability. Especially in the internet environment, the security and credibility of financial data are even more critical issues.

[0003] In recent years, blockchain technology, due to its decentralized, immutable, and traceable characteristics, has been considered an effective solution to the problems of traditional financial systems. However, existing blockchain financial systems still face many technical bottlenecks in practical applications. Firstly, there is the performance issue; public blockchains typically achieve only single-digit to tens of transactions per second (TPS), far from meeting the demands of high-frequency financial transactions. Secondly, there is the privacy protection issue; the transparency of blockchain fundamentally contradicts the privacy requirements of financial data, making it crucial to protect trade secrets while ensuring data verifiability. Furthermore, existing systems lack innovation in audit process design, often requiring the retrieval of raw data for verification, which impacts efficiency and increases the risk of privacy breaches. Summary of the Invention

[0004] The technical problem to be solved by this invention is the key issues of performance bottlenecks, privacy leaks, and auditing difficulties in traditional financial systems and existing blockchain financial solutions. To this end, we propose an Internet big data processing financial system.

[0005] To achieve the above objectives, this application adopts the following technical solution: an Internet big data processing financial system, comprising:

[0006] The business processing module is used to adapt to and receive multi-source heterogeneous raw financial data, obtain encrypted data through a symmetric encryption algorithm, and generate a certificate package based on preset financial compliance rules.

[0007] The evidence storage certificate includes a first hash value, a zero-knowledge proof, and a storage address. The first hash value is obtained by performing SHA-256 operation on the original data. The zero-knowledge proof is generated by its internal zero-knowledge proof generation unit, which can prove that it complies with compliance rules without disclosing the original data.

[0008] The data availability storage module communicates bidirectionally with the business processing module, receives encrypted data and stores it through a distributed architecture, and generates a unique storage address to be fed back to the business processing module.

[0009] The high-speed consensus notarization module communicates unidirectionally with the business processing module. After receiving the notarization certificate package, it completes consensus verification through a permissioned network composed of 10-100 trusted nodes and uses an aBFT-type consensus algorithm to record the notarization transaction containing the first hash value, storage address and zero-knowledge proof in the first blockchain.

[0010] The anchoring module communicates with the high-speed consensus storage module and the second blockchain respectively, monitors the first blockchain in real time, extracts the block header hash as status information at preset intervals, and sends it to the second blockchain for recording.

[0011] The audit verification module communicates with the business processing module, the high-speed consensus notarization module, and the second blockchain. When responding to an audit request, it calculates the second hash value of the data to be audited, matches it with the notarized transactions on the first blockchain, calls the public key to verify the zero-knowledge proof, verifies the anchoring status of the second blockchain, and outputs the audit results.

[0012] Preferably, the business processing module includes a zero-knowledge proof generation unit, which is equipped with a zero-knowledge proof circuit. The zero-knowledge proof circuit generates the zero-knowledge proof by using the original financial data as private input and the first hash value and the preset financial business rule identifier as public input.

[0013] Preferably, the financial business rules include at least one of the following rules: transaction amount validity rules, transaction timestamp compliance rules, account information format correctness rules, debit and credit balance rules, and anti-money laundering compliance rules.

[0014] Preferably, the business processing module further includes a data preprocessing unit and an encryption unit; the data preprocessing unit is used to perform format parsing, cleaning and standardization on multi-source heterogeneous raw financial data; the encryption unit is used to call the key management service to obtain a symmetric encryption key and encrypt the standardized data.

[0015] Preferably, the data availability storage module adopts a content-addressable distributed storage architecture, the unique storage address is a content identifier, and the module is configured with a storage proxy service for handling encrypted data upload, storage, and address return.

[0016] Preferably, the trusted node is operated by at least two of the following types of institutions: financial institutions, accounting firms, regulatory agencies, and large enterprises.

[0017] Preferably, the anchoring module includes an anchoring smart contract deployed on the second blockchain and an independently operating cross-chain bridge relay; the cross-chain bridge relay is used to perform the real-time monitoring, extraction, and sending operations; the preset interval is triggered when the first blockchain generates a fixed number of new blocks.

[0018] Preferably, the workflow of the audit verification module specifically includes:

[0019] Calculate the second hash value of the data to be audited;

[0020] Query the stored transactions on the first blockchain whose transaction hash value matches the second hash value;

[0021] Obtain the corresponding zero-knowledge proof and storage address from the evidence storage transaction;

[0022] The validity of the zero-knowledge proof is verified using the public verification key corresponding to the generated zero-knowledge proof;

[0023] Query the anchoring record of the first blockchain block where the evidence exchange is located on the second blockchain;

[0024] By combining the zero-knowledge proof verification results with the anchored state, a trustworthy audit report is generated that includes data authenticity, compliance, and global trust level.

[0025] Preferably, the Internet big data processing financial system further includes an application access module, which is equipped with a unified data source access gateway. The gateway supports receiving multi-source heterogeneous raw financial data through at least one of the following methods: RESTful API, message queue subscription, and database change data capture.

[0026] Preferably, the first blockchain is a permissioned blockchain dedicated to the storage of financial data, and its blocks only store data fingerprints, storage addresses, zero-knowledge proofs and transaction metadata.

[0027] The technical effects and advantages of this invention are as follows:

[0028] This invention combines a permissioned blockchain with a high-speed consensus storage layer and a mature public blockchain with a trusted anchoring layer through a layered blockchain architecture. Utilizing the aBFT consensus algorithm, it achieves second-level consensus and a transaction processing capacity of tens of thousands of transactions per second, fundamentally changing the current situation where public blockchains suffer from low TPS and cannot meet the demands of high-frequency financial transactions. The core processing module, built upon zero-knowledge proof technology, resolves the fundamental contradiction between blockchain transparency and financial data privacy. It completes data compliance proof without disclosing original business secrets. Combined with auditing, it achieves efficient verification without retrieving original data, significantly shortening audit time and avoiding privacy risks. This effectively meets the security and compliance needs of various scenarios such as e-commerce transactions, corporate finance, and cross-border payments. Attached Figure Description

[0029] The disclosure of this invention is illustrated with reference to the accompanying drawings. It should be understood that the drawings are for illustrative purposes only and are not intended to limit the scope of protection of this invention. In the drawings, the same reference numerals are used to refer to the same parts:

[0030] Figure 1 This is a flowchart of the system of the present invention;

[0031] Figure 2 This is a flowchart of the data auditing process for this invention. Detailed Implementation

[0032] It is readily understood that, based on the technical solution of this invention, those skilled in the art can propose various interchangeable structural methods and implementations without altering the essential spirit of the invention. Therefore, the following detailed embodiments and accompanying drawings are merely illustrative examples of the technical solution of this invention and should not be considered as the entirety of the invention or as limitations or restrictions on the technical solution of this invention.

[0033] Reference Figures 1-2 As shown, the present invention provides a technical solution: an Internet big data processing financial system, comprising:

[0034] The business processing module is used to adapt to and receive multi-source heterogeneous raw financial data, obtain encrypted data through a symmetric encryption algorithm, and generate a certificate package based on preset financial compliance rules. The business processing module includes a zero-knowledge proof generation unit, which is equipped with a zero-knowledge proof circuit. The zero-knowledge proof circuit uses the raw financial data as private input and the first hash value and the preset financial business rule identifier as public input to generate a zero-knowledge proof. The financial business rules include at least one of the following rules: transaction amount validity rule, transaction timestamp compliance rule, account information format correctness rule, debit and credit balance rule, and anti-money laundering compliance rule.

[0035] After the business processing module starts, it automatically associates with the unified gateway of the application access module and receives multi-source data from RESTful API interfaces, message queues, or database change captures, including Excel data exported from different financial software, JSON data of bank transaction records, and structured database data from the enterprise ERP system. It loads at least one financial business rule from the preset rule base, such as transaction amount validity rules, setting upper or lower limits for single transaction amounts, foreign exchange rate ranges, transaction timestamp compliance rules, limiting the transaction time to within the enterprise's operating hours and not earlier than the system's activation time, account information format correctness rules, verifying the length of bank account numbers, compliance of opening bank codes, taxpayer identification number format, debit and credit balance rules, automatically checking whether the total debit amount and total credit amount of each account are equal, anti-money laundering compliance rules, comparing whether the counterparty's account is on the anti-money laundering blacklist, and monitoring large and frequent transfers.

[0036] The business processing module continuously monitors the data transmission channel maintained by the unified gateway. Through a real-time push receiving mechanism or a periodic active retrieval strategy, it obtains unprocessed raw data packets. Based on the unique identifier of the data source, the module dynamically calls the appropriate parser to transform raw data of different formats, such as Excel spreadsheets, JSON text, or database record streams, into intermediate data objects with unified internal specifications. Depending on the specific type of the data object, such as bank transfer records or sales invoice information, the module automatically matches and loads one or more corresponding financial business rule templates from the pre-set rule library. It then dynamically fills the actual field values ​​in the current data object, including key attributes such as transaction amount and timestamp, into the corresponding parameter positions of the rule template, thereby generating an executable rule verification instance.

[0037] In this process, the system uses the raw financial data, after complete parsing and standardization, as the private input to the zero-knowledge proof circuit. Simultaneously, it calculates the hash value of this data processed by the SHA-256 algorithm, outputting the first hash value. This hash value is then combined with the unique identifier of the currently selected rule template to form the public input to the zero-knowledge proof circuit. Subsequently, the zero-knowledge proof generation unit calls the pre-compiled proof logic circuit, combining the private and public inputs, and using the proof key pre-generated through a secure multi-party computation ritual, to perform complex cryptographic calculations, ultimately generating a concise and cryptographically secure zero-knowledge proof.

[0038] This proof effectively verifies the following fact: there exists a certain original data whose hash result is completely consistent with the provided first hash value, and the data fully complies with all business logic constraints and verification conditions corresponding to the rule identifier, thereby achieving verifiable data compliance proof without exposing the original data.

[0039] The business processing module also includes a data preprocessing unit and an encryption unit; the data preprocessing unit is used to parse, clean and standardize the format of multi-source heterogeneous raw financial data; the encryption unit is used to call the key management service to obtain the symmetric encryption key and encrypt the standardized data.

[0040] The data preprocessing unit performs a detailed data cleaning and standardization process on the parsed intermediate data objects. Specific cleaning operations include identifying and removing duplicate records, using appropriate imputation or default value filling strategies for missing values ​​in key fields, and correcting obvious formatting errors, such as converting diverse date formats from different sources into a standardized format. After cleaning, the unit maps the cleaned data to a unified standard structure based on a predefined global data schema, ensuring that the names, data types, and units of all data fields remain consistent throughout the system.

[0041] Subsequently, for each batch or each standardized data record, the encryption unit sends a key request to the key management service. The key management service queries or dynamically generates a unique AES-256 symmetric encryption key based on the tenant identifier and data type of the data, and securely returns it to the encryption unit. The encryption unit then uses this key to encrypt the standardized data that has been serialized into a byte stream, generating the corresponding ciphertext data.

[0042] After encryption, the system calculates the first hash value of the ciphertext data and generates a zero-knowledge proof that can be used for verification, while reserving storage address bits returned by the data availability storage module. These elements are packaged into a structured evidence credential package, and finally, the credential package is digitally signed to ensure the integrity, authenticity, and trustworthiness of the credential itself and the source of the operation.

[0043] The evidence storage certificate consists of three core components: a first hash value, a zero-knowledge proof, and a corresponding storage address. The first hash value is a digest obtained by performing a standardized SHA-256 hash operation on the original data, and it has the characteristics of irreversibility and uniqueness. The zero-knowledge proof is constructed by the system's built-in zero-knowledge proof generation unit, which can effectively prove that the data meets the preset compliance rules without exposing the specific content of the original data, thus taking into account both the credibility of data verification and the needs of privacy protection.

[0044] A bidirectional communication mechanism is established between the data availability storage module and the business processing module. This module is responsible for receiving encrypted data and achieving reliable data storage using a distributed system architecture. After storage, the module generates a globally unique storage address and sends it back to the business processing module for subsequent retrieval. The data availability storage module is implemented based on a content-addressed distributed storage architecture, which ensures that each storage object corresponds to a unique content identifier derived from the content itself. Furthermore, this module is configured with a dedicated storage proxy service, which is responsible for uniformly handling the entire process of encrypted data upload, persistent storage, and returning the storage address, ensuring the efficiency and security of the data processing.

[0045] After encrypting the data, the encryption unit in the business processing module transmits the generated ciphertext data, along with the unique data ID corresponding to the ciphertext, the encryption algorithm identifier, and other necessary metadata information, to the storage proxy service of the data availability storage module via a standardized API call. Upon receiving the ciphertext and related information, the storage proxy service immediately initiates a hash operation, performing a hash calculation on the ciphertext data. The resulting hash value serves as the unique content identifier (CID) for the ciphertext. Subsequently, the storage proxy service distributes the ciphertext data to a pre-configured distributed storage cluster, specifically including an IPFS network or other types of decentralized storage networks, achieving persistent data storage and high availability through multi-node redundancy. After completing the storage operation, the storage proxy service returns the generated content identifier as the access address for the ciphertext in the distributed storage system via an API response to the business processing module. Upon receiving the content identifier, the business processing module accurately fills it into the reserved storage address field of the previously constructed evidence storage credential package, thereby completing the final assembly and generation of the entire evidence storage credential package.

[0046] The high-speed consensus notarization module and the business processing module adopt a one-way communication mechanism. The business processing module broadcasts the complete notarization certificate package with digital signature as a notarization transaction to the P2P network structure of the high-speed consensus notarization module. The transaction pool of each consensus node is responsible for receiving and temporarily storing the transaction. When the current consensus round starts, the selected specific node collects a batch of unprocessed notarization transactions from its transaction pool and performs digital signature validity verification and transaction format compliance checks on these transactions.

[0047] After successful verification, the node packages the transactions into a new candidate block and broadcasts the candidate block to all validator nodes. Each validator node then independently verifies each transaction contained in the block, especially performing fast format verification on the attached zero-knowledge proofs. However, the complete zero-knowledge proof verification process is not performed at this stage to ensure processing efficiency.

[0048] Meanwhile, after receiving the evidence storage credential package from the business processing module, the high-speed consensus evidence storage module processes it further through a permissioned network of 10 to 100 trusted nodes. These trusted nodes are jointly operated by at least two types of institutions, including financial institutions, accounting firms, regulatory agencies, and large enterprises. The network employs an asynchronous Byzantine fault-tolerant consensus algorithm to complete the consensus verification of the evidence storage transaction.

[0049] After verification, the system will write the notarized transaction record, which includes the first hash value, the corresponding storage address, and the relevant zero-knowledge proof, into the first blockchain. This first blockchain is a permissioned chain specifically for financial data notarization. Each block stores only the data fingerprint, namely the hash value, storage address, zero-knowledge proof, and necessary transaction metadata, to ensure efficient data management and audit compliance.

[0050] The anchoring module establishes communication connections with the high-speed consensus storage module and the second blockchain respectively, continuously monitors the operating status of the first blockchain in real time, and extracts the latest block header hash value as key status information according to the preset time or block interval, and then securely sends it to the second blockchain for trusted recording and storage.

[0051] The anchoring module mainly consists of two core components: first, an anchoring smart contract deployed on the second blockchain network, responsible for receiving, verifying, and persistently storing state data from the first blockchain; and second, an independently deployed and continuously running cross-chain bridge relay, which undertakes the actual monitoring, data extraction, and cross-chain transmission functions. The cross-chain bridge relay is responsible for performing key operations such as real-time monitoring, hash extraction, and data transmission. The preset interval is usually triggered by the first blockchain generating a fixed number of new blocks, ensuring that the system performs anchoring within a reasonable period.

[0052] The cross-chain bridge repeater continuously monitors block generation events on the first blockchain via an event subscription mechanism. Whenever a newly confirmed block is detected in the first blockchain network, a counter inside the repeater automatically increments. When the counter reaches a preset interval threshold, the repeater immediately triggers the anchoring operation process. First, it accesses the first blockchain node, reads the latest block header data at the corresponding height, and accurately extracts its block header hash value. Then, the repeater uses its own private key to sign the data, constructs and sends a transaction that invokes the anchored smart contract on the second blockchain. The core of Yi is to call the commit checkpoint function declared in the contract. The function parameters include the current block height of the first blockchain and the extracted block header hash. After the anchor transaction is received by the second blockchain network, it is packaged and confirmed through consensus verification. Once the confirmation is completed, the state snapshot formed by the corresponding block height and hash value is permanently and immutably recorded on the second blockchain, thus becoming an authoritative trust anchor point for the block state of the first blockchain in this cycle. After completing this round of anchoring, the relay automatically resets the counter to zero and restarts listening to and counting blocks in the next cycle.

[0053] As a core component of the trusted data auditing system, the audit verification module establishes communication connections with the business processing module, the high-speed consensus notarization module, and the second blockchain system. When responding to external audit requests, this module ensures data credibility through multiple verification mechanisms. The specific process includes calculating the second hash value of the data to be audited, matching it with the corresponding notarization transaction in the first blockchain, calling the public verification key to verify the zero-knowledge proof, checking the cross-chain anchoring status on the second blockchain, and finally generating a comprehensive audit report.

[0054] The complete workflow of the audit verification module is as follows:

[0055] First, the received raw data file to be audited undergoes standardized preprocessing to ensure consistency with the data format used during initial notarization. Then, a hash value is generated using the SHA-256 algorithm, serving as the second hash value. Next, a query request is initiated to the blockchain explorer or full node of the high-speed consensus notarization module to retrieve all notarization transaction records on the first blockchain whose data hash fields are completely consistent with this second hash value. If a matching record is found, the first hash value and rule identifier used in the corresponding zero-knowledge proof are extracted. Finally, the proof is cryptographically verified using a public verification key paired with the zero-knowledge proof generation circuit. Successful verification indicates that the data to be audited matches the original notarized data. Completely consistent and in accordance with preset business rules, the module further queries the anchoring smart contract of the second blockchain based on the height of the first blockchain where the evidence exchange is located to see if the block has been successfully anchored, and obtains relevant status information such as the anchoring time. Finally, the module comprehensively analyzes the following three key verification results: whether the evidence record exists, whether the zero-knowledge proof is valid, and whether the anchoring of the second blockchain has been completed. Based on this, a detailed structured audit report is generated. The report clearly marks each verification result and makes a comprehensive evaluation of the authenticity, compliance, and overall trust level of the data, ensuring the reliability, traceability, and immutability of the audit results, and is suitable for audit scenarios with high security requirements.

[0056] The Internet big data processing financial system also includes an application access module. The application access module is equipped with a unified data source access gateway. The gateway supports receiving multi-source heterogeneous raw financial data through at least one of the following methods: RESTful API, message queue subscription, and database change data capture.

[0057] In the configuration interface, system administrators can configure adapter types and corresponding connection parameters in detail according to different data source types, including key information such as database address, port, and authentication method. When the adapter receives input from various data sources, it first performs protocol-level parsing to complete identity authentication and security verification. Then, it stores the valid data payload in a high-throughput, low-latency internal message buffer. This buffer plays a crucial role in traffic smoothing and system decoupling, ensuring the stability of data reception and business processing in high-concurrency scenarios. The data preprocessing unit in the business processing module acts as a consumer, asynchronously pulling data from the buffer and initiating subsequent data cleaning, transformation, and standardization processes. At the same time, the gateway component will completely record key logs of all data access events, including timestamps, sources, data sizes, etc., for system monitoring, troubleshooting, and security auditing.

[0058] After system startup, each core module completes its initialization process sequentially, establishing a secure communication link based on encryption technologies such as TLS. The unified gateway in the application access module receives multi-source heterogeneous financial data through various methods, including RESTful API interfaces, asynchronous message queue transmission, and database modifications. Before data enters the system, the gateway performs strict permission verification and data format validity checks to ensure the reliability of the data source and the standardization of the data structure. After successful verification, the data is forwarded to the business processing module for subsequent operations.

[0059] The business processing module first performs parsing, cleaning, and standardization preprocessing on the received financial data to ensure data quality and consistency. Then, the system loads pre-defined financial business rules, such as the validity range of transaction amounts and the compliance requirements of timestamps, and initiates a zero-knowledge proof generation process. Using the original financial data as private input and the first hash value obtained through SHA-256 hashing and the rule identifier as public input, a GPU-accelerated engine efficiently generates a zero-knowledge proof to verify that the data conforms to business rules without leaking original information. Simultaneously, the module calls the key management service to obtain an AES-256-GCM encryption key and encrypts the standardized data. Finally, the system integrates the first hash value, the generated zero-knowledge proof, and the content identifier returned by the data availability storage module to generate a digitally signed evidence package, ensuring its integrity and non-repudiation.

[0060] Upon receiving encrypted data, the data availability storage module performs fragmentation and distributed backup storage, ensuring high availability and durability through redundancy mechanisms. It also generates a unique content identifier and returns it to the business processing module. The high-speed consensus notarization module utilizes a permissioned network of 10 to 100 trusted institutional nodes and employs an aBFT-like consensus algorithm to conduct efficient three-round communication consensus on the notarization credential package, ensuring rapid agreement in a distributed environment. The final notarization transaction is then recorded in the first blockchain. This blockchain is designed to store only lightweight metadata to improve overall system performance and scalability.

[0061] The anchoring module monitors the state of the first blockchain in real time. Whenever a certain number of new blocks are generated, it automatically extracts the latest block header hash and calls the anchoring smart contract on the second blockchain through the cross-chain relayer. This anchors the state integrity of the first blockchain to a wider range of trusted environments, achieving cross-chain immutability and finality.

[0062] When the audit verification module receives an audit request, it calculates the second hash value of the data to be audited and matches it with the corresponding evidence-stored transaction record in the first blockchain. The module calls a publicly verifiable zero-knowledge proof verification algorithm to confirm the validity of the data business compliance proof and verify whether its anchoring status on the second blockchain is successful and has not been tampered with. Finally, the system generates a detailed and trustworthy audit report, which includes the data authenticity, compliance status, and global trust level assessment, providing a comprehensive and reliable technical basis for the audit work.

[0063] Example 1: This example describes the specific application of the present invention in the medical insurance settlement and auditing scenario. A medical insurance institution needs to process a massive number of settlement documents submitted by medical institutions to ensure the authenticity of treatment items, drugs, and costs, prevent fraud and abuse of medical insurance, and at the same time meet the requirements of real-time settlement and strong supervision of medical insurance.

[0064] The deployment architecture of the medical insurance audit system is centered around the medical insurance platform. The application access layer connects with hospital information systems, pharmacy management systems, and insured individuals' mobile applications via standardized APIs, receiving structured data such as electronic medical records, prescriptions, and expense lists in real time. The business processing layer integrates a medical compliance rule engine; the rule base consists of payment policies for drugs, treatment items, service facilities, and clinical pathways. The consensus nodes of the high-speed consensus-based evidence storage chain are jointly operated by the National Healthcare Security Administration, the National Health Commission, large tertiary hospitals, and third-party auditing institutions. The trusted anchoring layer connects to a credible government or judicial evidence storage chain, and the data availability layer uses dedicated cloud storage that meets medical data security standards.

[0065] After an insured person completes medical treatment at a hospital, the encrypted expense data package generated by the hospital's information system, which includes a medical record summary, item details, and amount, is pushed to the medical insurance system via a dedicated network. The business processing layer completes two parallel operations within milliseconds: first, it calculates the reimbursement amount according to the policy and completes real-time settlement and payment; second, it initiates the zero-knowledge proof pipeline.

[0066] The zero-knowledge proof circuit is pre-loaded with complex medical business rules, ensuring that prescription drugs are within the medical insurance catalog, treatment items match diagnostic codes, examination frequencies comply with clinical guidelines, and total costs do not exceed the disease-specific budget. The system generates a zero-knowledge proof using encrypted raw medical data as private input and cost hashes and rule IDs as public inputs. This proof can demonstrate to auditors that the treatment and billing are fully compliant without disclosing sensitive information such as patient disease details and medication information.

[0067] All settlement records and their compliant zero-knowledge proofs, along with the fee hashes, are packaged and stored on a high-speed consensus chain. The National Healthcare Security Administration, large tertiary hospitals, and third-party auditing institutions on the full blockchain network jointly witness and confirm the immutability of each settlement. After the daily settlement is completed, the block hashes are anchored to the government blockchain, forming a legally valid regulatory evidence chain.

[0068] The National Healthcare Security Administration or auditing agencies can conduct multi-dimensional audits:

[0069] By inputting a time period, the system can quickly verify the zero-knowledge proof of all evidence records within that period, instantly outputting the overall compliance rate and anomaly warnings. This replaces the traditional manual sampling of medical records. For suspected fraud cases alerted or reported by the system, the auditor only needs to submit the number or hash of the suspicious document. After the system locates the record on the blockchain, the auditor can verify its compliance by verifying the zero-knowledge proof, or apply for a specific judicial authorization key to decrypt and retrieve the original data to delve into the details.

[0070] By linking drug procurement chain data with prescription settlement data on the blockchain, it is possible to verify whether the prescribed drugs are genuine products procured through centralized procurement, thus eliminating the loophole that allows drug dealers to illegally collect drugs and then claim reimbursement.

[0071] Example 2: This example describes its application in a supply chain finance scenario. A core enterprise and its multi-tiered suppliers have a large amount of accounts receivable. Traditional accounts receivable financing suffers from difficulties in confirming ownership, transferring assets, and high fraud risks, such as duplicate financing. This system aims to transform accounts receivable into trustworthy, divisible, and transferable digital assets.

[0072] The application access layer connects to core enterprise ERP systems, such as procurement, receiving, and payment modules, supplier management systems, and financial institution platforms. The core of the business processing layer is the trade background authenticity verification rule engine. The nodes of the high-speed consensus evidence storage chain are core enterprises, first- to N-level suppliers, partner banks, and factoring companies, while the anchoring layer connects to the blockchain infrastructure of the financial industry.

[0073] For every digital purchase order or goods receipt confirmation issued by the core enterprise, the relevant data, including the order number, amount, supplier, goods information, and delivery date, are immediately used by the business processing layer to generate a zero-knowledge proof. The core rules of the proof include that the order has been validly signed and sealed by the core enterprise, the goods have been delivered as agreed, and the accounts payable have not been repeatedly confirmed or paid.

[0074] After successful confirmation of rights, the system generates a digital accounts receivable certificate with an on-chain zero-knowledge proof. This certificate contains the account hash, the electronic signature of the core enterprise's payment commitment, and a zero-knowledge proof proving the authenticity of the trade. The certificate itself can be regarded as a crypto-digital asset with inherent credit and self-proof of innocence.

[0075] Tier 1 suppliers can split and transfer all or part of the amount of the digital accounts receivable voucher to their upstream Tier 2 suppliers to pay for goods. Each split, transfer, and pledge financing operation is recorded on the blockchain as a new transaction and comes with a corresponding zero-knowledge proof.

[0076] When banks or factoring companies receive financing applications from suppliers based on digital accounts receivable certificates, they do not need to conduct time-consuming and labor-intensive manual trade background investigations. They only need to verify the zero-knowledge proof attached to the DRP certificate online to confirm the authenticity, uniqueness, and outstanding status of the accounts receivable at the cryptographic level. Regulatory agencies join the network as observation nodes and can monitor the total scale, flow path, and financing status of accounts receivable across the entire chain in real time. They can use smart contracts to automatically warn of systemic risks such as excessive financing and financing maturity mismatch of core enterprises, but they do not have the right to view the sensitive trade details of specific enterprises.

[0077] The technical scope of this invention is not limited to the content described above. Those skilled in the art can make various modifications and variations to the above embodiments without departing from the technical concept of this invention, and all such modifications and variations should fall within the protection scope of this invention.

Claims

1. An internet big data processing financial system, characterized in that, include: The business processing module is used to adapt to and receive multi-source heterogeneous raw financial data, obtain encrypted data through a symmetric encryption algorithm, and generate a certificate package based on preset financial compliance rules. The evidence storage credential package includes a first hash value, a zero-knowledge proof, and a storage address. The first hash value is obtained by performing SHA-256 operation on the original data. The zero-knowledge proof is generated by its internal zero-knowledge proof generation unit, which can prove that it complies with compliance rules without disclosing the original data. The data availability storage module communicates bidirectionally with the business processing module, receives encrypted data and stores it through a distributed architecture, and generates a unique storage address to be fed back to the business processing module. The high-speed consensus notarization module communicates unidirectionally with the business processing module. After receiving the notarization certificate package, it completes consensus verification through a permissioned network composed of 10-100 trusted nodes and uses an aBFT-type consensus algorithm to record the notarization transaction containing the first hash value, storage address and zero-knowledge proof in the first blockchain. The anchoring module communicates with the high-speed consensus storage module and the second blockchain respectively, monitors the first blockchain in real time, extracts the block header hash as status information at preset intervals, and sends it to the second blockchain for recording. The audit verification module communicates with the business processing module, the high-speed consensus notarization module, and the second blockchain respectively. When responding to an audit request, it calculates the second hash value of the data to be audited, matches the notarized transactions of the first blockchain, calls the public key to verify the zero-knowledge proof, verifies the anchoring status of the second blockchain, and outputs the audit results. The workflow of the audit verification module specifically includes: Calculate the second hash value of the data to be audited; Query the stored transactions on the first blockchain whose transaction hash value matches the second hash value; Obtain the corresponding zero-knowledge proof and storage address from the evidence storage transaction; The validity of the zero-knowledge proof is verified using the public verification key corresponding to the generated zero-knowledge proof; Query the anchoring record of the first blockchain block where the evidence exchange is located on the second blockchain; By combining the zero-knowledge proof verification results with the anchored state, a trustworthy audit report is generated that includes data authenticity, compliance, and global trust level.

2. The Internet big data processing financial system according to claim 1, characterized in that: The business processing module includes a zero-knowledge proof generation unit, which is equipped with a zero-knowledge proof circuit. The zero-knowledge proof circuit generates the zero-knowledge proof by taking the original financial data as private input and taking the first hash value and the preset financial business rule identifier as public input.

3. The Internet big data processing financial system according to claim 2, characterized in that: The financial and business rules include at least one of the following rules: transaction amount validity rules, transaction timestamp compliance rules, account information format correctness rules, debit and credit balance rules, and anti-money laundering compliance rules.

4. The Internet big data processing financial system according to claim 1, characterized in that: The business processing module also includes a data preprocessing unit and an encryption unit; the data preprocessing unit is used to perform format parsing, cleaning and standardization on multi-source heterogeneous raw financial data; the encryption unit is used to call the key management service to obtain a symmetric encryption key and encrypt the standardized data.

5. The Internet big data processing financial system according to claim 1, characterized in that: The data availability storage module adopts a content-addressable distributed storage architecture, and the unique storage address is a content identifier. The data availability storage module is configured with a storage proxy service for handling encrypted data upload, storage, and address return.

6. The Internet big data processing financial system according to claim 1, characterized in that: The trusted nodes are operated by at least two of the following types of institutions: financial institutions, accounting firms, regulatory agencies, and large enterprises.

7. The Internet big data processing financial system according to claim 1, characterized in that: The anchoring module includes an anchoring smart contract deployed on the second blockchain and an independently operating cross-chain bridge relay; the cross-chain bridge relay is used to perform the real-time monitoring, extraction and sending operations; the preset interval is triggered when the first blockchain generates a fixed number of new blocks.

8. The Internet big data processing financial system according to claim 1, characterized in that: The Internet big data processing financial system also includes an application access module. The application access module is equipped with a unified data source access gateway. The gateway supports receiving multi-source heterogeneous raw financial data through at least one of the following methods: RESTful API, message queue subscription, and database change data capture.

9. The Internet big data processing financial system according to claim 1, characterized in that: The first blockchain is a permissioned blockchain dedicated to the storage of financial data, and its blocks only store data fingerprints, storage addresses, zero-knowledge proofs, and transaction metadata.

Images