A supply chain bill asset securitization system based on zero-knowledge proof and core enterprise credit penetration conduction

Abstract

This invention provides a supply chain bill securitization system based on zero-knowledge proofs and core enterprise credit penetration, comprising a bill on-chain module, a credit transmission module, an asset pool management module, a smart contract execution module, and an investor interface module. The bill on-chain module uses zero-knowledge proof circuits to verify the authenticity of bills and business compliance constraints, achieving on-chain anti-replay protection. Addressing the compliance issue of aggregated amounts of multiple sub-bills under the same contract, it performs cross-bill amount aggregation verification while protecting privacy. The credit transmission module transmits the core enterprise's credit to end-user suppliers. The asset pool management module automatically adjusts the over-collateralization ratio and executes asset swaps. The smart contract execution module enables cross-institutional atomic settlement. This invention resolves the contradiction between bill privacy protection and compliance verification in supply chain bill securitization scenarios, as well as the technical challenges of multi-level credit transmission and dynamic asset risk control.

Description

Technical Field

[0001] This invention relates to the field of electronic digital data processing, specifically to a supply chain bill securitization system based on zero-knowledge proof and core enterprise credit penetration transmission. Background Technology

[0002] Supply chain bill securitization is a financing method that aggregates commercial drafts, accounts receivable, and other bill assets in the supply chain into a special purpose vehicle and issues securities to the capital market. Existing technological solutions have varying degrees of shortcomings in areas such as bill authenticity verification, credit transmission, asset risk control, and cross-institutional settlement. During the bill registration phase, verification agencies must obtain complete original information about the bills to complete verification. There is an irreconcilable conflict between protecting commercial privacy and ensuring credible verification. Furthermore, existing solutions cannot effectively verify the compliance of the aggregated amounts of multiple bills under the same contract without obtaining the explicit amounts of each bill. Regarding credit transmission, existing supply chain finance solutions typically stop at confirming accounts payable between the core enterprise and first-tier suppliers. Second-tier and lower-tier suppliers lack verifiable credit endorsements and cannot obtain financing support equivalent to the core enterprise's credit, resulting in significantly higher financing costs for end-user suppliers. Regarding asset pool management, the status of the underlying assets of special purpose vehicles (SPVs) relies on periodic manual audits, and the over-collateralization ratio is fixed, making it impossible to adjust in real time according to changes in maturity dates, repayment rates, and concentration. Investors also cannot obtain real-time information on the true status of the underlying assets. In terms of cross-institutional settlement, the delivery of on-chain electronic debt instruments and fund transfers are processed by different systems, lacking atomicity guarantees. Furthermore, existing solutions typically rely on guarantees from a central counterparty, introducing additional credit risk exposure. These issues constrain the large-scale application of supply chain bill securitization and the overall financing efficiency of market participants.

[0003] In the prior art, patent publication number CN121599764A discloses a dynamic revenue calculation system for the entire lifecycle of supply chain bill asset securitization. This system includes a data access module, a dual-engine calculation module, a visualization output module, and a dynamic verification module. The data access module supports manual parameter input, automatic import of bill asset package details, and direct connection to the bill exchange interface to obtain bill data. The dual-engine calculation module runs a role-based revenue model and a cash flow path tracking model in parallel, calculating the revenue of each participant and simulating time-series capital inflows and outflows. The visualization output module generates a penetrating analysis report. The dynamic verification module compares the predicted values ​​before creation with the actual calculated values ​​after creation and generates a deviation analysis report. However, the above solution only addresses revenue calculation and cash flow simulation during the asset securitization process, failing to address privacy protection and compliance verification issues during the bill on-chain registration stage. It also lacks the technical means to transmit core enterprise credit to multi-level suppliers, and cannot solve core technical issues such as the authenticity verification of underlying bill assets and cross-institutional atomic settlement. Summary of the Invention

[0004] The purpose of this invention is to address the shortcomings by proposing a supply chain bill securitization system based on zero-knowledge proof and core enterprise credit penetration transmission.

[0005] The present invention adopts the following technical solution:

[0006] A supply chain bill securitization system based on zero-knowledge proof and core enterprise credit penetration transmission includes a bill on-chain module, a credit transmission module, an asset pool management module, a smart contract execution module, and an investor interface module. Each module operates collaboratively based on a permissioned blockchain network.

[0007] The bill on-chain module is configured to load the structured elements of the bill as private input variables into a zero-knowledge proof circuit with an arithmetic framework based on a rank-one constraint system. The circuit synchronously performs compliance constraint verification, generates a proof and a public digest, and completes the registration of the bill's unique identifier on the chain.

[0008] The credit transmission module is configured to generate on-chain electronic debt certificates based on the private key signature of the core enterprise, and to perform multi-level splitting and endorsement signature appending on the on-chain electronic debt certificates in response to the supplier's splitting request, forming a sub-certificate carrying a complete endorsement chain.

[0009] The asset pool management module is configured to calculate three parameters in real time: maturity concentration, historical repayment rate, and single debtor concentration of on-chain electronic debt certificates in the asset pool. Based on the superimposed calculation results of the three parameters, the module automatically adjusts the over-collateralization ratio and automatically triggers a shortfall notification or asset replacement process when an asset gap is detected.

[0010] The smart contract execution module is configured to perform atomic settlement of cross-institutional transactions based on hash time lock contracts, and to simultaneously trigger the transfer of ownership of on-chain electronic debt certificates and the transfer of funds on the blockchain using hash preimage as the unlocking condition.

[0011] The investor interface module is configured to respond to query requests from licensed investors by directly reading asset pool status data from the permissioned blockchain network status database and returning it to the investor terminal.

[0012] Furthermore, the bill-on-chain module converts the structured elements of the bill into finite field elements modulo the order of the elliptic curve BN254 scalar field and then loads them into the zero-knowledge proof circuit. The structured elements of the bill include the issuer's identifier, the payee's identifier, the face value, the maturity date, and the trade contract number.

[0013] Furthermore, the compliance constraints include the following three categories:

[0014] The amount range constraint is achieved by introducing two auxiliary variables to represent the difference between the face value and the lower limit of the amount dynamically configured by the system parameter contract, and the difference between the upper limit of the amount and the face value, respectively. Arithmetic is achieved by applying bit decomposition nonnegativity constraints to the two auxiliary variables.

[0015] The deadline compliance constraint is arithmetically achieved by applying a non-negativity constraint to the difference between the maturity date and the current block timestamp and verifying that the difference is not less than the minimum financing term specified by the system.

[0016] The institutional coding format constraint is arithmetically achieved by applying equality constraints to the high-order segment and check segment of the ticket issuer identifier field.

[0017] The three types of constraints are embedded in the same circuit and verified locally in one go. The on-chain verification contract simultaneously confirms the authenticity and compliance of the bill by verifying the validity of the proof.

[0018] Furthermore, the on-chain module for bills is also configured to perform a hash operation on the structured elements of the bill and the field element representation of the submitter's private key using the Poseidon hash function within the zero-knowledge proof circuit to generate a one-time random number, and submit the one-time random number as a public output along with the proof to the on-chain verification contract.

[0019] The on-chain verification contract maintains a set of registered random numbers with a sparse Merkle tree as the data structure. It performs non-membership proof verification on newly submitted one-time random numbers. After the verification is successful, the hash value of the one-time random number is written into the sparse Merkle tree and the root state variable is updated.

[0020] The unique identifier of the bill is formed by hashing the public digest and the one-time random number.

[0021] Furthermore, the bill on-chain module also includes a cross-bill aggregation constraint circuit, configured to handle the compliance verification of the amount aggregation of multiple sub-bills under the same trade contract;

[0022] The cross-note aggregation constraint circuit uses the face value of each sub-note and its corresponding blinding factor, and the total contract commitment blinding factor as private inputs, and the Pedersen commitment, total contract commitment and aggregation commitment of each sub-note as public inputs. The circuit synchronously verifies the commitment consistency constraint, the summation upper limit constraint and the blinding factor consistency constraint.

[0023] The on-chain verification contract verifies the validity of the aggregated proof and the consistency between the aggregated commitment and the sum of the commitments of each sub-note, confirming that the sum of the amounts of all sub-notes meets the contract upper limit constraint without obtaining the plaintext of any sub-note amount;

[0024] The cross-ticket aggregation constraint circuit and the single-ticket independent verification circuit share the same proof system and trusted setting parameters.

[0025] Furthermore, the on-chain module for invoices is also configured to perform intersection detection on the set of goods batch identifiers carried by each sub-invoice under the same contract. The intersection detection is implemented on-chain through a Bloom filter with a preset upper limit for the false positive rate.

[0026] If the detection result indicates suspected overlap, the on-chain verification contract triggers an off-chain arbitration process requiring the submitter to provide a batch identifier in plaintext for precise verification.

[0027] Furthermore, the data structure of the on-chain electronic debt certificate includes a unique identifier for the certificate, the original debt amount, the current holder's address, the core enterprise's signature, the validity period, and a divisible flag.

[0028] When the credit transmission module performs the split, each sub-certificate inherits the original signature of the core enterprise and adds the endorsement signature of the current holder. The credit transmission module verifies the hierarchical continuity of the endorsement chain from the core enterprise's signature to the current holder's signature to confirm that the credit rating carried by the sub-certificate is equivalent to the original accounts payable of the core enterprise.

[0029] Furthermore, the asset pool management module takes the benchmark over-collateralization ratio as a starting point. When the concentration on the maturity date exceeds the first threshold, a first increment is added to the benchmark value. When the historical repayment rate is lower than the second threshold, a second increment is added to the current value. When the concentration of a single debtor exceeds the third threshold, a third increment is added to the current value. The three increments can be calculated cumulatively, and the adjustment result is automatically executed by the smart contract.

[0030] Furthermore, the smart contract execution module locks the on-chain electronic debt certificate to be delivered on the asset chain, and locks the corresponding funds on the capital chain, and records the hash value and time window of the hash preimage to the hash time lock contract state storage.

[0031] Once the payee submits the hash preimage within the time window and passes the verification, the smart contract execution module simultaneously triggers the on-chain transfer of asset ownership and the on-chain fund transfer.

[0032] If no valid submission is received before the time window expires, the smart contract execution module performs a rollback operation on the locked resources of the dual-chain system.

[0033] Furthermore, the asset pool status data that the investor interface module opens to licensed investors includes the total number of on-chain electronic debt certificates in the pool, the weighted average maturity date, the current rating trigger parameters of the tiered assets, and the most recent overcollateralization ratio adjustment record. This data is read directly from the permissioned blockchain network status database and is not forwarded through intermediary nodes.

[0034] The beneficial effects achieved by this invention are:

[0035] The on-chain module for bills in this system maps the structured elements of bills to private input variables of a zero-knowledge proof circuit. It synchronously embeds three types of compliance constraints—amount range, maturity compliance, and institutional coding format—within the circuit. This allows on-chain verification nodes to simultaneously verify the authenticity of bills and business compliance without obtaining any original bill elements, fundamentally resolving the contradiction between bill privacy protection and trusted verification. For scenarios involving the splitting of multiple sub-bills under the same contract, a cross-bills aggregation constraint circuit designed based on the homomorphic addition property of Pedersen commitments enables on-chain contracts to complete the compliance verification of the sum of multiple bill amounts without obtaining any plaintext of sub-bill amounts, eliminating the irreconcilable contradiction between over-financing risk and privacy protection in existing solutions. The anti-replay mechanism derives a one-time random number internally bound to both the bill content and the submitter's identity, and combines this with a sparse Merkle tree to achieve on-chain uniqueness constraints, fundamentally eliminating the on-chain operational space for double staking and multiple financing.

[0036] The credit transmission module enables the credit of core enterprises to be transmitted to second-tier and lower-tier suppliers through the multi-level splitting and endorsement chain mechanism of on-chain electronic debt certificates. End suppliers can directly initiate financing applications based on the credit of core enterprises, breaking through the limitation of credit transmission only to the first level in existing supply chain finance solutions, and effectively reducing the financing costs of end suppliers.

[0037] To further understand the features and technical content of the present invention, please refer to the following detailed description and drawings of the present invention. However, the drawings provided are for reference and illustration only and are not intended to limit the present invention. Attached Figure Description

[0038] Figure 1 This is a schematic diagram of the overall structural framework of the present invention;

[0039] Figure 2 This is a schematic diagram of the invoice on-chain module process of the present invention;

[0040] Figure 3 This is a schematic diagram of the cross-document aggregation constraint circuit of the present invention;

[0041] Figure 4 This is a schematic diagram of the on-chain electronic debt certificate splitting process of the credit transmission module of the present invention;

[0042] Figure 5 This is a schematic diagram of the over-collateralization ratio adjustment process of the asset pool management module of the present invention. Detailed Implementation

[0043] The following specific embodiments illustrate the implementation of the present invention. Those skilled in the art can understand the advantages and effects of the present invention from the content disclosed in this specification. The present invention can be implemented or applied through other different specific embodiments, and various details in this specification can also be modified and changed based on different viewpoints and applications without departing from the spirit of the present invention. Furthermore, the accompanying drawings of the present invention are for simple illustrative purposes only and are not depictions of actual dimensions; this is stated beforehand. The following embodiments will further describe the relevant technical content of the present invention in detail, but the disclosed content is not intended to limit the scope of protection of the present invention.

[0044] Example 1.

[0045] This embodiment provides a supply chain bill securitization system based on zero-knowledge proofs and the credit penetration transmission of core enterprises, combined with... Figure 1 It consists of five functional modules: a bill on-chain module, a credit transmission module, an asset pool management module, a smart contract execution module, and an investor interface module. Each module operates collaboratively based on a permissioned blockchain network.

[0046] Combination Figure 2 The bill on-chain module is responsible for the on-chain trusted registration of bill elements such as commercial drafts and accounts receivable vouchers in the supply chain scenario. The bill on-chain module adopts a zero-knowledge concise non-interactive knowledge demonstration mechanism to verify the authenticity of bills and business compliance. The specific implementation method is as follows:

[0047] At the circuit construction level, the holder of the bill loads the structured elements of the bill—including the issuer's identifier, the payee's identifier, the face value, the maturity date, and the trade contract number—as private input variables into the zero-knowledge proof circuit in an off-chain environment.

[0048] The on-chain module for bills uses a rank-one constraint system as the arithmetic framework of the circuit. The rank-one constraint system expresses each constraint in the circuit as the inner product relationship between three vectors a, b, c and the proof vector w, that is, (a·w)×(b·w) =(c·w), where w contains all the input variables, intermediate variables and output variables of the circuit. Before being loaded into the circuit, each private input variable of the bill element is first transformed into a field element on a finite field.

[0049] The circuit simultaneously embeds three types of business compliance constraints during the proof generation phase:

[0050] The first is the amount range constraint, which verifies whether the face value of the invoice falls within the upper and lower limits of the single transaction amount permitted by regulations. The constraint expression is as follows: ≤ A ≤ ,in and The system parameters are dynamically configured by the contract. The circuit only outputs a Boolean result indicating whether the constraint is satisfied or not, and does not output the specific value of A.

[0051] Secondly, there is the deadline compliance constraint, where the circuit calculates the expiration date D and the current block timestamp. The difference is used to verify whether it is not lower than the minimum financing period stipulated by the system. The constraint expression is D - ≥ ;

[0052] Thirdly, there is the constraint of the organization coding format. The circuit performs bit segment verification on the binary code of the ticket issuer's identifier to verify whether it conforms to the predefined organization coding specification. Specifically, equality constraints are applied to the high bit segment and the check bit segment of the identifier field respectively.

[0053] The above three types of constraints are embedded in the same circuit and verified locally in one go. The on-chain contract does not need to obtain the original values ​​of the face value, maturity date or issuer identifier. It can simultaneously confirm the authenticity and compliance of the bill by verifying the validity of π, thus achieving the unification of "compliance proof" and "authenticity proof", which is different from the general zero-knowledge proof scheme that only performs existence verification.

[0054] To ensure replay protection and on-chain uniqueness, a one-time random number N is introduced into the circuit input. The derivation of N is completed within the zero-knowledge circuit, using the drawer's identifier, face value, due date, and submitter's private key as inputs to the Poseidon hash function. The output is N, and the derivation rule is N = Poseidon(drawer's identifier || face value || due date || submitter's private key), where || represents field concatenation. N is a public output variable in the circuit, and its correct derivation process is protected by circuit constraints. Any derivation attempt that tampers with the input elements or private key cannot be verified through proof, thus ensuring that the binding relationship between N and the ticket content and submitter's identity is cryptographically unforgeable.

[0055] N, as one of the circuit's public outputs, is submitted to the on-chain verification contract along with the proof π. The verification contract first checks whether N already exists in the registered random number set S: if N already exists, the contract determines that this submission is a duplicate on-chain request and rejects it, while recording the rejection event in the on-chain log; if N does not exist, the contract continues to perform the proof validity verification. After the verification passes, N is written into the set S, and the unique identifier and digest h of the ticket are registered. Since the derivation process of N depends on the submitter's private key, different submitters will inevitably generate different Ns for the same ticket. The contract can reject duplicate on-chain requests without obtaining any original ticket information by using the uniqueness constraint of N.

[0056] Set S uses a sparse Merkle tree data structure to store the hash value of N. The sparse Merkle tree has a height of 254 levels, matching the bit width of the BN254 scalar field. The contract verifies that N has not yet been registered by verifying non-membership proofs. After successful verification, the hash value of N is inserted into the tree and the root is updated. The root is stored on-chain as a contract state variable. Compared to directly maintaining a mapping table, the sparse Merkle tree structure keeps the on-chain computational overhead of set member verification operations at the O(log n) level and supports off-chain generation of membership proofs or non-member proofs for third-party verification, enhancing the auditability of the anti-replay mechanism.

[0057] The unique identifier of a bill is composed of a digest h and N, denoted as ID = Hash(h ‖ N), which ensures that the on-chain identifiers of the same bill do not collide at different submitters and at different submission times, fundamentally eliminating the on-chain operation space for double pledging and multiple financing.

[0058] Combination Figure 3 At the cross-document association constraint verification level, the on-chain document module designed a cross-document aggregation constraint circuit based on the homomorphic addition property of Pedersen commitments, as specifically implemented as follows:

[0059] During the commitment generation phase, the holder of the i-th sub-note under the same contract locally commits its face value. Generate Pedersen commitments The commitment calculation method is as follows Where G and H are two generators on the elliptic curve BN254. The blinding factor is randomly generated locally by the holder. Submitted as a public value to the on-chain contract and It is retained locally as a private value by the holder.

[0060] Pedersen commitments possess the additive homomorphic property, meaning that the sum of the points on the elliptic curve of multiple commitments equals the sum of their corresponding amounts. The expression is: The on-chain contract obtains the aggregate commitment by performing elliptic curve point addition on the registered sub-note commitments. This operation can be completed without obtaining any plaintext of Aᵢ.

[0061] During the contract total commitment generation stage, the contract total amount M is committed by the core enterprise when the contract is confirmed. , The contract ownership information will be stored on the blockchain along with the contract details. It is held by the core enterprise.

[0062] During the aggregation constraint circuit verification phase, each sub-note holder jointly constructs an aggregation proof, and the circuit uses each... ,each and For private input, each , and aggregation commitment For public inputs, verify the following three constraints internally within the circuit:

[0063] One is the commitment consistency constraint, which verifies each Established to ensure that the commitments submitted by each holder are consistent with their private amounts;

[0064] The second is the summation upper limit constraint, which is verified. This inequality constraint is implemented internally by introducing a non-negative auxiliary variable. Arithmeticization is achieved by applying a bit decomposition nonnegativity constraints to e;

[0065] Thirdly, the consistency constraint of the blinding factor is verified. With aggregate commitment The total amount of blinding factor implied in the process is consistent, ensuring the correctness of the aggregation commitment.

[0066] The above three constraints are verified in a single circuit, and the circuit outputs a single aggregate proof. On-chain contracts are verified effectiveness and With each By verifying the consistency of the results, it can be confirmed that the sum of the amounts of all sub-notes under this contract meets the upper limit constraint without obtaining the plaintext of the amounts of any sub-notes.

[0067] At the batch non-overlap constraint verification level, in order to prevent the same batch of goods from being repeatedly covered by multiple sub-tickets, each sub-ticket carries a set of corresponding goods batch identifiers in the circuit input, and the hash value of the batch identifier set is stored on the chain as a public output.

[0068] When the on-chain contract receives a new sub-note submission, it retrieves all batch identifier hash values ​​registered under the same contract item. If the newly submitted batch identifier set intersects with any of the registered sets, it is determined to be an overlap and the submission is rejected.

[0069] The intersection detection of batch identifier sets is implemented on-chain using a Bloom filter, with the false positive rate of the Bloom filter configured to be no higher than [previous value]. To achieve a balance between on-chain computational overhead and detection accuracy;

[0070] In the event of suspected overlap due to misjudgment by the Bloom filter, the contract triggers an off-chain arbitration process requiring the submitter to provide the batch identifier in plaintext for accurate verification.

[0071] The aforementioned cross-document aggregation constraint circuit and single-document independent verification circuit share the same proof system and trusted setting parameters, eliminating the need for additional trusted setting and aggregation proof. The size is the same as that of a single-ticket proof, fixed at 192 bytes. The on-chain verification overhead does not increase with the number of sub-tickets, maintaining constant-level verification complexity.

[0072] Combination Figure 4 The credit transmission module enables the chain transmission of accounts payable confirmation information from the core enterprise to multi-level suppliers. Within the system, the core enterprise confirms the amount of accounts payable to the first-level supplier through private key signing. The system generates an on-chain electronic debt certificate for the confirmed accounts payable. The data structure of the on-chain electronic debt certificate includes: a unique identifier for the certificate, the original debt amount, the current holder's address, the core enterprise's signature, the validity period, and a splittable flag.

[0073] When a Tier 1 supplier needs to settle payments with a Tier 2 supplier, it can invoke a splitting contract to split the on-chain electronic debt certificate it holds into several sub-certificates based on the amount. Each sub-certificate inherits the original signature of the core enterprise and adds the endorsement signature of the Tier 1 supplier, forming a traceable multi-level endorsement chain.

[0074] Sub-certificates held by suppliers at level 2 and below carry a complete endorsement chain. The system verifies the integrity of the endorsement chain and the validity of the core enterprise's signature to confirm that the credit rating carried by the sub-certificate is equivalent to the original accounts payable of the core enterprise. This enables downstream suppliers to initiate financing applications based on the credit of the core enterprise, breaking through the limitation in traditional supply chain finance that credit can only be transmitted to the first level.

[0075] Combination Figure 5 The asset pool management module is responsible for the dynamic status maintenance and risk parameter monitoring of the special purpose vehicle asset pool. Using smart contracts as the execution vehicle, the module tracks in real time three parameters: the maturity date distribution, historical repayment rate, and concentration of single debtors among the on-chain electronic debt instruments within the pool. Based on these parameters, it calculates the current required overcollateralization ratio R, according to the following rules:

[0076] Based on the benchmark over-collateralization ratio Starting from this point, when the proportion of on-chain electronic debt securities in the pool with maturity dates concentrated within the next 30 days exceeds a certain threshold... At that time, R was Add to the basis ;

[0077] When the historical collection rate is lower than the threshold When R increases from its current value, ;

[0078] When the proportion of the on-chain electronic debt certificate corresponding to a single debtor to the total pool exceeds the threshold When R increases from its current value, .

[0079] The above three increments can be calculated cumulatively, and the adjustment of the over-collateralization ratio is automatically executed by the contract without manual approval.

[0080] When there is a gap between the actual value of the assets in the pool and the required overcollateralization amount, the contract automatically triggers two types of disposal processes:

[0081] One is the shortfall compensation notification, which sends an on-chain notification to the asset originator and sets a response deadline;

[0082] Secondly, there is asset swap. If the difference is not made up within the response period, the contract will automatically extract compliant on-chain electronic debt certificates from the pre-registered candidate asset queue and add them to the asset pool, while removing the substandard assets. The entire process does not rely on external manual intervention.

[0083] The smart contract execution module is responsible for atomic settlement of cross-institutional transactions within the system. For scenarios where multiple institutions such as banks, securities companies, and factoring companies participate in the same transaction, the smart contract execution module adopts a cross-chain atomic delivery protocol based on hash time-lock contracts. The initiator locks the on-chain electronic debt certificate to be delivered on the asset chain and locks the corresponding funds on the funding chain. Both parties use the same hash preimage R as the unlocking condition and set a time window T. The payee submits R within the time window to unlock the funds. This action simultaneously triggers the transfer of ownership of the on-chain electronic debt certificate on the asset chain. If R is not submitted before the time window expires, the locked assets and funds of both parties are automatically rolled back to the initial state.

[0084] The above mechanism ensures that the delivery of on-chain electronic debt instruments and the transfer of funds are completed simultaneously at the protocol level, eliminating the risk of settlement mismatch in cross-institutional settlements and eliminating the need to introduce a central counterparty for guarantee.

[0085] The investor interface module provides investors in asset-backed securities with real-time and transparent access to the underlying assets. Through the permissioned blockchain's query interface, the investor interface module opens up asset pool status data to licensed investors, including the total number of on-chain electronic debt certificates in the pool, the weighted average maturity date, the current rating trigger parameters of the tiered assets, and the most recent over-collateralization ratio adjustment record. All data is read directly from the on-chain status without the need for intermediaries, and the immutability of the data is guaranteed by the underlying blockchain.

[0086] With the coordinated operation of the above five modules, the overall system processing flow is as follows:

[0087] Suppliers submit invoices to the invoice on-chain module to complete zero-knowledge concise non-interactive knowledge verification and obtain a unique identifier for the invoice;

[0088] After the on-chain electronic debt certificate completes multi-level endorsement through the credit transmission module, it is collected and submitted by the asset originator to a special purpose vehicle;

[0089] The asset pool management module continuously monitors risk parameters for collected assets and automatically adjusts the over-collateralization ratio.

[0090] After the issuance of asset-backed securities products, each redemption is completed atomically through the smart contract execution module;

[0091] Investors can obtain the status of the underlying assets in real time through the investor interface module.

[0092] Example 2:

[0093] This embodiment introduces the hardware configuration of a supply chain bill securitization system based on zero-knowledge proof and core enterprise credit penetration transmission, including a bill on-chain unit, a credit transmission unit, an asset pool management unit, a smart contract execution unit, and an investor interface unit. Each unit works collaboratively through the communication bus of the permissioned blockchain network nodes.

[0094] The on-chain unit for bills includes an off-chain proof processor and an on-chain verification processor;

[0095] The off-chain proof processor is deployed on the local node of the ticket holder and configured to perform the following operations:

[0096] The system receives input of structured elements of a negotiable instrument, and after converting the issuer identifier, payee identifier, face value, due date, and trade contract number into finite domain elements, it loads them into the rank-one constraint system circuit.

[0097] The circuit performs verification operations for three types of compliance constraints, including bit decomposition operations for amount range constraints, difference non-negativity operations for period compliance constraints, and bit segment equality verification operations for institutional coding format constraints.

[0098] The Poseidon hash function is invoked to perform a hash operation on the ticket elements and the submitter's private key to generate a one-time random number N and a digest h;

[0099] The output proof π is combined with the public parameters and sent to the on-chain verification processor.

[0100] The on-chain verification processor is deployed on the verification nodes of the permissioned blockchain network. It is configured to call the BN254 elliptic curve pairing pre-compilation function to perform validity verification on the received proof π, maintain a set of registered random numbers S with a sparse Merkle tree as the data structure, perform non-membership proof verification on the newly submitted random number N, and write the hash value of N into the sparse Merkle tree and update the root state variable after the verification is passed. At the same time, it registers the unique identifier of the ticket ID = Hash(h ‖ N).

[0101] The on-chain unit for bills also includes an aggregation proof processor, which is configured to receive Pedersen commitments submitted by each sub-bill holder when multiple sub-bills are on-chain in parallel under the same contract, perform elliptic curve point addition operations to generate aggregation commitments, and perform validity verification and commitment consistency verification on the aggregation proof jointly constructed by each sub-bill holder, and maintain a Bloom filter to perform intersection detection of the batch identifier set.

[0102] The credit transmission unit includes a rights confirmation processor and a contract splitting processor.

[0103] The rights confirmation processor is configured to receive the private key signature input from the core enterprise and generate an on-chain electronic debt certificate based on the signed and confirmed accounts payable amount. The data structure of the on-chain electronic debt certificate is stored in the state database of the permissioned blockchain network and includes six fields: unique identifier of the certificate, original debt amount, current holder address, core enterprise signature, validity period, and divisibility flag.

[0104] The split contract processor is configured to respond to the supplier's split request, perform a split operation on the currently held on-chain electronic debt certificate according to the amount specified in the request, generate several sub-certificates, append the current holder's endorsement signature to each sub-certificate, and perform integrity verification on the endorsement chain of the sub-certificate to confirm the hierarchical continuity of the endorsement chain from the core enterprise's signature to the current holder's signature.

[0105] The asset pool management unit includes a parameter monitoring processor and an automatic adjustment actuator.

[0106] The parameter monitoring processor is configured to read in real time the maturity date field, historical repayment rate records, and holder address information of each on-chain electronic debt certificate in the asset pool within the permissioned blockchain network status database. It then calculates the current values ​​of three parameters: maturity date concentration, historical repayment rate, and single debtor concentration, and compares them with the system-configured threshold parameters. , , Perform comparison operations.

[0107] The automatic adjustment executor configuration is set to perform the superposition calculation of the over-collateralization ratio R based on the comparison results of the parameter monitoring processor, and write the calculation results into the state variables of the asset pool management contract;

[0108] When an asset shortfall is detected, the on-chain message sending operation for the shortfall compensation notification and the operation for extracting and replacing compliant credentials from the alternative asset queue are executed sequentially.

[0109] The smart contract execution unit includes an asset locking processor and an atomic settlement processor.

[0110] The asset locking processor is configured to receive and lock on-chain electronic debt certificates to be delivered on the asset chain, receive and lock corresponding funds on the funding chain, and record the hash value of the hash preimage R and the time window T in the state storage of the hash time lock contract.

[0111] The atomic settlement processor is configured to listen to the hash preimage R submitted by the payee on the fund chain, and after verifying that it is consistent with the hash value recorded at the time of locking, synchronously trigger the state write operation of the ownership transfer of the on-chain electronic debt certificate on the asset chain.

[0112] If no valid hash preimage submission is received after the time window T expires, a rollback operation will be performed on the locked resources on the asset chain and the capital chain.

[0113] The investor interface unit includes a query processor configured to respond to query requests from licensed investors. It directly reads the total number of on-chain electronic debt certificates in the asset pool, the weighted average maturity date, the current rating trigger parameters of the tiered assets, and the most recent over-collateralization ratio adjustment record from the state database of the permissioned blockchain network. The processor encapsulates the above data into a query response and returns it to the investor terminal. The query processor does not forward data through any intermediary nodes, and the integrity of the query results is guaranteed by the consensus mechanism of the permissioned blockchain network.

[0114] The aforementioned units exchange data through the communication bus of the permissioned blockchain network nodes. The unique identifier of the bill output by the bill-on-chain unit is transmitted to the credit transmission unit via the communication bus as the input basis for generating on-chain electronic debt certificates. The on-chain electronic debt certificates output by the credit transmission unit are transmitted to the asset pool management unit via the communication bus to perform risk parameter monitoring. The state variables of the asset pool management unit are granted read access to the smart contract execution unit and the investor interface unit via the communication bus.

[0115] The content disclosed above is only a preferred and feasible embodiment of the present invention, and is not intended to limit the scope of protection of the present invention. Therefore, all equivalent technical changes made based on the content of the present invention specification and drawings are included within the scope of protection of the present invention. Furthermore, the elements therein can be updated as technology develops.

Claims

1. A supply chain bill securitization system based on zero-knowledge proof and core enterprise credit penetration transmission, characterized in that, It includes a bill on-chain module, a credit transmission module, an asset pool management module, a smart contract execution module, and an investor interface module. Each module operates collaboratively based on a permissioned blockchain network. The bill on-chain module is configured to load the structured elements of the bill as private input variables into a zero-knowledge proof circuit with an arithmetic framework based on a rank-one constraint system. The circuit synchronously performs compliance constraint verification, generates a proof and a public digest, and completes the registration of the bill's unique identifier on the chain. The credit transmission module is configured to generate on-chain electronic debt certificates based on the private key signature of the core enterprise, and to perform multi-level splitting and endorsement signature appending on the on-chain electronic debt certificates in response to the supplier's splitting request, forming a sub-certificate carrying a complete endorsement chain. The asset pool management module is configured to calculate three parameters in real time: maturity concentration, historical repayment rate, and single debtor concentration of on-chain electronic debt certificates in the asset pool. Based on the superimposed calculation results of the three parameters, the module automatically adjusts the over-collateralization ratio and automatically triggers a shortfall notification or asset replacement process when an asset gap is detected. The smart contract execution module is configured to perform atomic settlement of cross-institutional transactions based on hash time lock contracts, and to simultaneously trigger the transfer of ownership of on-chain electronic debt certificates and the transfer of funds on the blockchain using hash preimage as the unlocking condition. The investor interface module is configured to respond to query requests from licensed investors by directly reading asset pool status data from the permissioned blockchain network status database and returning it to the investor terminal.

2. The supply chain bill securitization system based on zero-knowledge proof and core enterprise credit penetration transmission as described in claim 1, characterized in that, The on-chain module for bills converts the structured elements of the bill into finite field elements modulo the order of the elliptic curve BN254 scalar field and then loads them into the zero-knowledge proof circuit. The structured elements of the bill include the issuer's identifier, the payee's identifier, the face value, the maturity date, and the trade contract number.

3. The supply chain bill securitization system based on zero-knowledge proof and core enterprise credit penetration transmission as described in claim 2, characterized in that, The compliance constraints include the following three categories: The amount range constraint is achieved by introducing two auxiliary variables to represent the difference between the face value and the lower limit of the amount dynamically configured by the system parameter contract, and the difference between the upper limit of the amount and the face value, respectively. Arithmetic is achieved by applying bit decomposition nonnegativity constraints to the two auxiliary variables. The deadline compliance constraint is arithmetically achieved by applying a non-negativity constraint to the difference between the maturity date and the current block timestamp and verifying that the difference is not less than the minimum financing term specified by the system. The institutional coding format constraint is arithmetically achieved by applying equality constraints to the high-order segment and check segment of the ticket issuer identifier field. The three types of constraints are embedded in the same circuit and verified locally in one go. The on-chain verification contract simultaneously confirms the authenticity and compliance of the bill by verifying the validity of the proof.

4. The supply chain bill securitization system based on zero-knowledge proof and core enterprise credit penetration transmission as described in claim 3, characterized in that, The on-chain module for bills is also configured to perform a hash operation on the structured elements of the bill and the field element representation of the submitter's private key using the Poseidon hash function within the zero-knowledge proof circuit to generate a one-time random number, and submit the one-time random number as a public output along with the proof to the on-chain verification contract. The on-chain verification contract maintains a set of registered random numbers with a sparse Merkle tree as the data structure. It performs non-membership proof verification on newly submitted one-time random numbers. After the verification is successful, the hash value of the one-time random number is written into the sparse Merkle tree and the root state variable is updated. The unique identifier of the bill is formed by hashing the public digest and the one-time random number.

5. The supply chain bill securitization system based on zero-knowledge proof and core enterprise credit penetration transmission as described in claim 4, characterized in that, The bill on-chain module also includes a cross-bill aggregation constraint circuit, configured to handle the compliance verification of the amount aggregation of multiple sub-bills under the same trade contract; The cross-note aggregation constraint circuit uses the face value of each sub-note and its corresponding blinding factor, and the total contract commitment blinding factor as private inputs, and the Pedersen commitment, total contract commitment and aggregation commitment of each sub-note as public inputs. The circuit synchronously verifies the commitment consistency constraint, the summation upper limit constraint and the blinding factor consistency constraint. The on-chain verification contract verifies the validity of the aggregated proof and the consistency between the aggregated commitment and the sum of the commitments of each sub-note, confirming that the sum of the amounts of all sub-notes meets the contract upper limit constraint without obtaining the plaintext of any sub-note amount; The cross-ticket aggregation constraint circuit and the single-ticket independent verification circuit share the same proof system and trusted setting parameters.

6. The supply chain bill securitization system based on zero-knowledge proof and core enterprise credit penetration transmission as described in claim 5, characterized in that, The on-chain module for bills is also configured to perform intersection detection on the set of goods batch identifiers carried by each sub-bill under the same contract. The intersection detection is implemented on-chain through a Bloom filter with a preset upper limit for the false positive rate. If the detection result indicates suspected overlap, the on-chain verification contract triggers an off-chain arbitration process requiring the submitter to provide a batch identifier in plaintext for precise verification.

7. The supply chain bill securitization system based on zero-knowledge proof and core enterprise credit penetration transmission as described in claim 6, characterized in that, The data structure of the on-chain electronic debt certificate includes a unique identifier for the certificate, the original debt amount, the current holder's address, the core enterprise's signature, the validity period, and a splittable flag. When the credit transmission module performs the split, each sub-certificate inherits the original signature of the core enterprise and adds the endorsement signature of the current holder. The credit transmission module verifies the hierarchical continuity of the endorsement chain from the core enterprise's signature to the current holder's signature to confirm that the credit rating carried by the sub-certificate is equivalent to the original accounts payable of the core enterprise.

8. The supply chain bill securitization system based on zero-knowledge proof and core enterprise credit penetration transmission as described in claim 7, characterized in that, The asset pool management module starts with the benchmark over-collateralization ratio. When the concentration on the maturity date exceeds the first threshold, a first increment is added to the benchmark value. When the historical repayment rate is lower than the second threshold, a second increment is added to the current value. When the concentration of a single debtor exceeds the third threshold, a third increment is added to the current value. The three increments can be calculated cumulatively, and the adjustment result is automatically executed by the smart contract.

9. A supply chain bill securitization system based on zero-knowledge proof and core enterprise credit penetration transmission as described in claim 8, characterized in that, The smart contract execution module locks the on-chain electronic debt certificate to be delivered on the asset chain, and locks the corresponding funds on the capital chain at the same time, and records the hash value and time window of the hash preimage to the hash time lock contract state storage. Once the payee submits the hash preimage within the time window and passes the verification, the smart contract execution module simultaneously triggers the on-chain transfer of asset ownership and the on-chain fund transfer. If no valid submission is received before the time window expires, the smart contract execution module performs a rollback operation on the locked resources of the dual-chain system.

10. A supply chain bill securitization system based on zero-knowledge proof and core enterprise credit penetration transmission as described in claim 9, characterized in that, The asset pool status data that the investor interface module opens to licensed investors includes the total number of on-chain electronic debt certificates in the pool, the weighted average maturity date, the current rating trigger parameters of the tiered assets, and the most recent overcollateralization ratio adjustment record. This data is read directly from the permissioned blockchain network status database and is not forwarded through intermediary nodes.

Images