Blockchain-based credit whole-process evidence chain construction method and system

Abstract

The application proposes a blockchain-based credit whole-process evidence storage evidence chain construction method and system. The method comprises: obtaining the node state change record of the current credit business node, calling the preset evidence storage rule to generate a node evidence requirement set; generating an evidence summary node from the source system according to the node evidence requirement set, and constructing an evidence dependency chain containing a to-be-acquired position; positioning the evidence gap according to the to-be-acquired position, acquiring a corrected business record to generate a corrected evidence summary node, and connecting the corrected evidence summary node to the evidence dependency chain to generate a closed evidence chain; generating a closed-loop evidence package according to the closed evidence chain, writing an evidence package verification summary into a blockchain to generate an on-chain verification index. The application improves single-point evidence storage to evidence chain construction for business nodes, realizes complete closure and on-chain verification of credit whole-process evidence, and effectively improves the efficiency of auditing and judicial evidence.

Description

Technical Field

[0001] This invention belongs to the field of data processing, and in particular relates to a method and system for constructing a blockchain-based evidence chain for the entire credit process. Background Technology

[0002] Currently, electronic signatures, electronic contracts, electronic files, timestamps, hash verification, and blockchain-based evidence storage technologies are widely used in lending operations to preserve and track business materials. A common practice involves the core lending system, electronic signature system, account confirmation system, payment system, accounting system, post-loan management system, or collection system generating contract documents, signing records, account confirmation records, approval records, loan disbursement instructions, payment receipts, crediting results, repayment records, and notification delivery records, respectively. A hash digest is then generated for each document or business record, and the digest, timestamp, document number, signature serial number, or evidence storage number are written to the blockchain or electronic evidence storage platform to prove that the material existed at a certain time and that its content has not been tampered with. These technologies have a foundation for application in preventing tampering of single documents, electronic signature tracking, off-chain file storage, and post-event hash verification, and can improve problems such as the ease of loss of traditional paper files, high costs of manual verification, and lack of transparency in the material retrieval process. However, in real-world credit engineering scenarios, a loan is not constituted by a single contract or record, but rather spans multiple stages, including application, approval, signing, disbursement, post-loan management, collection, and settlement. Each stage generates evidence with sequential and supporting relationships from different business systems. For example, the disbursement stage typically requires the interconnectedness of contract signing, account confirmation, disbursement instructions, payment receipts, and account entry results; the collection stage typically requires the interconnectedness of overdue results, notification content, sending records, and delivery results. Existing evidence preservation methods mostly generate summaries and upload them to the blockchain after the materials are generated. While this can prove the existence of a certain material, it is difficult to determine whether the necessary evidence exists at the current credit stage before proceeding to the next process, nor is it easy to prove whether a certain business action is supported by prior evidence. Especially in scenarios such as asynchronous system receipts, material supplementation, delayed account confirmation, delayed payment results, and notification delivery corrections, existing systems typically only add materials or record anomalies. Determining the specific location of the gap in the evidence chain, whether the corrected materials originate from the original required source system, and whether the corrected materials truly reconnect to the original business support path often requires manual review of multiple systems. Furthermore, during audits, regulatory inquiries, business reviews, or judicial evidence presentations, financial institutions often have to export large amounts of original files and then manually interpret the relationships between the materials. This is not only inefficient but also prone to resulting in overly broad scope of irrelevant materials, exposure of sensitive information, and insufficient explanation of evidentiary relationships. Therefore, while existing technologies can achieve single-point material tamper-proofing and on-chain evidence storage, they still lack a robust mechanism closely integrated with the credit business process for determining the requirements for evidence at each node in the entire credit process, forming a dependency chain for evidence summaries, closing evidence gaps in situ, and forming an on-chain verifiable evidence package after closure. Summary of the Invention

[0003] This invention discloses a method and system for constructing a blockchain-based evidence chain for the entire credit process, in order to solve the problems mentioned in the background art.

[0004] To achieve the above objectives, the first aspect of the present invention provides a method for constructing a blockchain-based evidence chain for the entire credit process, the method comprising: Obtain the node status change records of the current credit business node, and call the pre-set evidence storage rules to generate the node evidence requirement set; Evidence summary nodes are generated from business records obtained from the source system based on the node evidence requirement set, and an evidence dependency chain is constructed based on the business support relationship; the evidence dependency chain includes the evidence summary nodes and the location to be obtained; Based on the location to be obtained in the evidence dependency chain, locate the evidence gap, obtain the correction business record to generate a correction evidence summary node, and connect the correction evidence summary node to the evidence dependency chain to generate a closed evidence chain. A closed-loop evidence package is generated based on the closed evidence chain, and the evidence package verification summary of the closed-loop evidence package is written into the blockchain to generate an on-chain verification index.

[0005] Further, the step of generating evidence digest nodes from business records obtained from the source system based on the node evidence requirement set includes: The business record is obtained from the source system according to the evidence requirement record in the node evidence requirement set; the evidence requirement record includes the evidence digest type, the source system, off-chain indexing rules, allowed on-chain field range, necessity identifier, and intra-node order; Based on the range of allowed on-chain fields, extract the verification fields to generate a normalized field string; The evidence digest node is generated by hashing the normalized field string.

[0006] Furthermore, the construction of the evidence dependency chain based on business support relationships includes: Generate a dependency edge summary based on the node order and the business support relationship; Construct the evidence dependency chain; the evidence dependency chain includes the evidence summary node, the position to be obtained, the dependency edge, and the incomplete dependency edge; the dependency edge includes the dependency edge summary.

[0007] Further, the step of locating the evidence gap based on the position to be obtained in the evidence dependency chain includes: Traverse the positions to be obtained and the incomplete dependency edges in the evidence dependency chain; When the preceding end of the incomplete dependency edge is the position to be obtained and the following end is the evidence summary node, the evidence gap is determined to be a preceding support evidence gap. When the preceding end of the incomplete dependency edge is the evidence digest node and the following end is the position to be obtained, the evidence gap is determined to be a post-result evidence gap; When both the front end and the back end are evidence digest nodes and the dependency edge digest is yet to be formed, the evidence gap is determined to be a support connection gap.

[0008] Further, the step of obtaining the correction business record to generate a correction evidence summary node, and connecting the correction evidence summary node to the evidence dependency chain to generate a closed evidence chain, includes: A gap record is generated based on the evidence gap; the gap record includes gap number, loan business number, current business node number, missing evidence summary type, source system, off-chain indexing rule, affected dependency type, business reason, necessity identifier, intra-node order, and gap generation time; The correction business record is obtained based on the source system and the off-chain indexing rule in the gap record; Hash the correction records to generate a correction evidence digest; Convert the location to be obtained into the corrected evidence summary node; Generate a summary of reconnection dependency edges based on the incomplete dependency edges; Based on the gap location information, the gap closure object summary, the reconnection dependency edge summary, the closure action identifier, and the in-situ constraint item, a closure binding summary is generated; Based on the original evidence dependency chain basic summary, the closed binding summary, and the current node closure sequence item, a closed chain summary is generated to obtain the closed evidence chain.

[0009] Further, generating a closed-loop evidence package based on the closed chain of evidence includes: Extract valid paths from the closed evidence chain to generate an evidence package directory; the evidence package directory includes an evidence digest node directory, a dependency edge directory, a gap closure directory, and an off-chain index directory; Generate the closed-loop evidence package; the closed-loop evidence package includes evidence package number, loan business number, current business node number, evidence summary node directory, dependent edge directory, gap closure directory, closed chain summary, off-chain index directory and generation time.

[0010] Further, the step of writing the evidence package verification digest of the closed-loop evidence package into the blockchain to generate an on-chain verification index includes: Based on the loan business number, the current business node number, the closed chain digest, the gap closure set string, the evidence package directory index string, and the certificate issuance action identifier, a hash calculation is performed to obtain the evidence package verification digest; Construct a blockchain evidence storage request; the blockchain evidence storage request includes the evidence package verification digest, the closed chain digest, the evidence package number, the loan business number, the current business node number, the off-chain index directory digest, the gap closure set string, the generation time, and the evidence storage system signature; The blockchain evidence storage request is sent to the blockchain evidence storage platform, and the on-chain transaction number and blockchain timestamp returned by the blockchain evidence storage platform are received. The on-chain verification index is generated based on the on-chain transaction number, block height, blockchain timestamp, evidence package verification digest, and evidence storage platform identifier.

[0011] Further, the step of extracting verification fields and generating a normalized field string based on the allowed range of on-chain fields includes: The verification fields are arranged according to fixed character encoding, fixed field order, and fixed separation method; For null values ​​in the verification fields, a preset null value identifier is written to the corresponding field position; The time field in the verification field is uniformly converted into a time string with a preset time zone and precision. The amount field in the verification field is standardized to a preset currency and decimal places. For sensitive fields in the verification fields, the de-identification identifier returned by the source system is used to participate in the digest construction to obtain the normalized field string.

[0012] Furthermore, the step of invoking pre-set evidence storage rules to generate a node evidence requirement set includes: Perform a consistency check based on the loan business number, business node number, and loan business type; After verification, the pre-set evidence storage rules are read using the business node number as the primary condition, and the rule entries are filtered using the loan business type as the secondary condition. Evidence requirements are generated and recorded according to the aforementioned rule entries; The method of recording the evidence requirement is determined based on the necessity markers in the rule entries; The evidence requirement records are arranged according to the node order in the pre-set evidence storage rules to generate the node evidence requirement set.

[0013] In a second aspect, the present invention provides a blockchain-based system for constructing a chain of evidence for the entire credit process, the system comprising: The node rule invocation module is used to obtain the node status change records of the current credit business node and invoke the preset evidence storage rules to generate the node evidence requirement set; The dependency chain construction module is used to obtain business records from the source system based on the node evidence requirement set to generate evidence summary nodes, and to construct an evidence dependency chain based on the business support relationship; the evidence dependency chain includes the evidence summary nodes and the location to be obtained; The closed evidence chain generation module is used to locate the evidence gap according to the position to be obtained in the evidence dependency chain, obtain the correction business record to generate the correction evidence summary node, and connect the correction evidence summary node to the evidence dependency chain to generate a closed evidence chain. The blockchain evidence storage module is used to generate a closed-loop evidence package based on the closed evidence chain, and write the evidence package verification summary of the closed-loop evidence package into the blockchain to generate an on-chain verification index.

[0014] The beneficial technical effects of the present invention are at least as follows: To address the aforementioned issues, this invention provides a blockchain-based method and system for constructing a full-process evidence chain for credit transactions. It elevates the single-point storage of credit materials to the construction of an evidence chain oriented towards business nodes. By generating a node evidence requirement set, it clarifies the evidence required for each node, solving the problem of existing technologies struggling to determine the completeness of node evidence. By constructing an evidence dependency chain, isolated stored materials are transformed into a chain structure reflecting the relationship between prerequisites and supporting evidence, proving that business actions are supported by prerequisite evidence. An in-situ closure mechanism is established for evidence gaps, ensuring that supplementary materials are obtained from the original designated source and reconnected to the original chain, resolving the issues of unclear relationships between supplementary materials and the original process and difficulty in verifying the closure process. Finally, a closed-loop evidence package containing the complete evidence path and gap closure process is generated and stored on the blockchain. Without expanding the scope of sensitive information on the chain, it achieves the retrieval, verification, and on-chain validation of the entire credit transaction evidence chain, significantly improving the efficiency and accuracy of auditing, regulatory retrieval, and judicial evidence presentation. Attached Figure Description

[0015] The present invention will be further described with reference to the accompanying drawings, but the embodiments in the drawings do not constitute any limitation on the present invention. For those skilled in the art, other drawings can be obtained based on the following drawings without creative effort.

[0016] Figure 1 This is a flowchart of the blockchain-based method for constructing a blockchain-based evidence chain for the entire credit process.

[0017] Figure 2 This is a system framework diagram for constructing a blockchain-based evidence chain for the entire credit process. Detailed Implementation

[0018] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0019] See Figure 1 , Figure 1 A flowchart illustrating a blockchain-based method for constructing a chain of evidence for the entire credit process, as provided in this embodiment of the invention. The method includes the following steps: Step S101: Obtain the node status change record of the current credit business node, and call the preset evidence storage rules to generate the node evidence requirement set.

[0020] Specifically, when a loan transaction enters stages such as application, approval, signing, loan disbursement, post-loan management, collection, or settlement, the core credit business system or credit process engine generates a node status change record and sends it to the evidence storage system via an internal interface. The node status change record identifies the current business stage of the loan transaction and includes the loan transaction number, business node number, business node name, loan transaction type, node status, and node occurrence time. The loan transaction number comes from the loan master table of the core credit business system and is used to associate a specific loan; the business node number and business node name come from the node configuration of the process engine and are used to distinguish between business nodes such as application, approval, signing, loan disbursement, post-loan management, collection, or settlement; the loan transaction type comes from the product or business type field in the core credit business system and is used to distinguish between business scenarios such as credit loans, mortgage loans, and secured loans; the node status comes from the workflow record of the process engine and is used to indicate the current node's entry, completion, cancellation, or return status; the node occurrence time comes from the business log of the process engine or the core credit business system and is used to record the time when this node status change occurred. After receiving a node status change record, the evidence storage system retrieves the corresponding loan's basic business information from the core credit business system based on the loan business number, and performs a consistency check on the loan business number, business node number, and loan business type. If the check passes, the evidence storage system enters the pre-set evidence storage rule invocation process; if the check fails, the system generates a node data anomaly record, recording the loan business number, business node number, loan business type, and reason for the anomaly, and terminates the current node's requirement set generation process.

[0021] Pre-configured evidence preservation rules are stored in an evidence preservation rule library. These rules are configured by financial institutions before system launch, based on business regulations, contract processes, electronic signature processes, loan disbursement processes, payment channel receipt processes, accounting entry processes, post-loan notification processes, and record-keeping requirements. The evidence preservation system uses the business node number as the primary condition for reading rules and the loan business type as a secondary condition for filtering rules, selecting only those rules that are active and in effect. For the same business node, different loan business types can be configured with different rule entries; when a business type uses general rules, the system reads the general rule entries for that business node. Taking the loan disbursement node as an example, the rule entries for a credit loan disbursement node typically include a contract signing summary, a receiving account confirmation summary, a loan disbursement instruction summary, a payment receipt summary, and an accounting entry result summary; mortgage loan disbursement nodes may also include a mortgage registration completion summary depending on the business regulations. When the current loan business type is a credit loan, the system reads the rule entries corresponding to the credit loan disbursement node, ensuring that the evidence requirements for the current node are consistent with the actual loan type. Each rule entry in the rule base corresponds to a type of evidence digest that needs to be obtained or generated subsequently. The rule entry content includes the evidence digest type, source system, off-chain index field, allowed on-chain field range, necessity identifier, and intra-node order. The evidence digest type describes the evidence digest that should be generated subsequently, such as a contract signing digest, receiving account confirmation digest, loan disbursement instruction digest, payment receipt digest, account entry result digest, repayment result digest, or delivery result digest. The source system limits the location from which subsequent business records are obtained, such as an electronic signature system, account confirmation system, credit core system, payment system, accounting system, notification system, or collection system. The off-chain index field locates the original business record, such as contract version number, signing serial number, account confirmation record number, loan disbursement instruction number, payment receipt number, or account entry record number. The allowed on-chain field range limits the scope of verification information subsequently written to the blockchain, including digest, number, version identifier, path digest, and timestamp. The necessity identifier distinguishes the role of the evidence digest in the current node closure. The intra-node order indicates the business sequence relationship between evidence digests within the same business node.

[0022] To ensure that subsequent summary generation and gap closure for the same node are based on the same rule definition, the evidence storage system simultaneously reads the rule version number, effective time, expiration time, and rule summary when reading rule entries, and writes them into the rule binding information of the node evidence requirement set. If the same business node and the same loan business type simultaneously match multiple enabled rules, the system first selects a unique rule version based on the rule's effective time and priority; if a unique version cannot be determined, a rule conflict record is generated, and the current node requirement set generation process ends, without generating a node evidence requirement set that can be used for subsequent summary calculations. If the current node undergoes asynchronous feedback correction or material supplementation in subsequent steps, the system still uses the rule version and rule summary frozen in this step, and does not change the node evidence requirements that have already entered the processing flow due to subsequent changes in the rule base configuration, thereby avoiding the use of different rules for the same credit node, which would lead to an unrecalculated evidence chain.

[0023] After reading the rule entries, the evidence storage system converts them into evidence requirement records corresponding to the current loan transaction. This conversion process revolves around the subsequent construction of the credit evidence chain, focusing on addressing inconsistencies in field naming and indexing methods across different business systems. In the electronic signature system, the field for locating the contract signing record can be the signing serial number; in the credit core system, the field for locating the loan disbursement instruction can be the loan disbursement instruction number; in the payment system, the field for locating the payment result can be the payment receipt number; and in the accounting system, the field for locating the accounting result can be the accounting record number. Based on pre-set evidence storage rules, the evidence storage system maps these fields to the corresponding off-chain index fields under the corresponding evidence digest type, ensuring that each evidence requirement record clearly indicates which source system, which index field, and which type of evidence digest should be obtained subsequently. Taking the credit loan disbursement node as an example, the system can generate five necessary evidence requirement records: The contract signing summary record must originate from the electronic signature system, with off-chain index fields including the loan business number, contract version number, and signing serial number, used for subsequent location of the contract signing record and generation of the contract signing summary; the payment account confirmation summary record must originate from the account confirmation system or the credit core system, with off-chain index fields including the loan business number and account confirmation record number, used for subsequent location of the payment account confirmation record and generation of the account confirmation summary; the loan disbursement instruction summary record must originate from the credit core system, with off-chain index fields including the loan business number and loan disbursement instruction number, used for subsequent location of the loan disbursement instruction record and generation of the loan disbursement instruction summary; the payment receipt summary record must originate from the payment system, with off-chain index fields including the loan business number and payment receipt number, used for subsequent location of the payment result returned by the payment channel; and the fund receipt result summary record must originate from the accounting system, with off-chain index fields including the loan business number and fund receipt record number, used for subsequent location of the fund receipt result. The aforementioned evidence requirements are based on business summaries and indexes, so that the subsequent evidence chain construction revolves around the evidence required for each node.

[0024] When generating evidence requirement records, the evidence storage system determines the usage of the record in the current node based on the necessity identifier in the rule entry. Necessary evidence requirement records are added to the node's evidence requirement set and serve as the basis for subsequent evidence dependency chain construction and evidence gap location. Supplementary evidence requirement records are added to the node's evidence requirement set when a corresponding business record number exists in the current business node and the rules allow its inclusion; these records supplement the business traces of the current node. For loan disbursement nodes, contract signing summaries, receiving account confirmation summaries, loan disbursement instruction summaries, payment receipt summaries, and deposit result summaries are typically used as necessary evidence requirement records. Internal remarks, manual explanations, or non-essential attachments are used as supplementary evidence requirement records when the rules are clearly configured and the business system has already generated corresponding records. Through the setting of necessity identifiers, the node's evidence requirement set can centrally retain the evidence summary requirements needed to close the current node, while also providing a clear rule basis for the inclusion of supplementary records. After all evidence requirement records are generated, the evidence storage system arranges them according to the node order in the pre-set evidence storage rules. Taking the loan disbursement node as an example, the order within the node can be as follows: contract signing summary requirement record, receiving account confirmation summary requirement record, loan disbursement instruction summary requirement record, payment receipt summary requirement record, and deposit result summary requirement record. This order is saved as part of the node evidence requirement set in this step and will be used in the next step to establish the business support relationship between evidence summaries after obtaining the actual evidence summaries.

[0025] When the evidence storage system fails to find an enabled rule corresponding to the current business node in the evidence storage rule base, the system creates a node rule missing record, recording the loan business number, business node number, loan business type, and reason for the missing rule, and terminates the requirement set generation process for the current node. When a read rule entry lacks a source system, off-chain index field, or evidence digest type, the system creates a rule entry exception record and marks the exception entry as pending configuration processing. After rule reading, field mapping, necessity determination, and intra-node sorting, the system generates a node evidence requirement set. The node evidence requirement set consists of multiple evidence requirement records corresponding to the current credit business node. Each evidence requirement record includes the evidence digest type, source system, off-chain index rule, allowed on-chain field range, necessity identifier, and intra-node order. The node evidence requirement set stores the structured requirements required for subsequent generation of evidence digests and construction of the evidence dependency chain. The off-chain index rule is used for subsequent location of business records, the allowed on-chain field range is used for subsequent formation of blockchain verification information, the necessity identifier is used for subsequent identification of evidence gaps, and the intra-node order is used for subsequent construction of the evidence dependency chain. The next step takes the node evidence requirement set as input, obtains or generates actual evidence digests according to the source system and off-chain indexing rules, and constructs an evidence dependency chain based on the intra-node order and business support relationship.

[0026] Step S102: Obtain business records from the source system according to the node evidence requirement set to generate evidence summary nodes, and construct evidence dependency chains according to business support relationships; the evidence dependency chain includes the evidence summary nodes and the locations to be obtained.

[0027] Specifically, the evidence storage system takes the node evidence requirement set output in step S101 as input, reads each evidence requirement record in it, and generates evidence summaries based on the evidence digest type, source system, off-chain indexing rules, allowed on-chain field range, necessity identifier, and intra-node order in each record. The evidence digest type in the node evidence requirement set determines which type of summary needs to be generated, such as contract signing summary, account confirmation summary, loan disbursement instruction summary, payment receipt summary, or deposit result summary; the source system determines the location of the business record; the off-chain indexing rules determine which specific business record to locate within the source system; the allowed on-chain field range determines which confirmatory fields participate in the summary construction; the necessity identifier determines the closing effect of the evidence digest in the subsequent evidence dependency chain; and the intra-node order determines the basis for arranging evidence digests within the same credit node. Through this process, the node evidence requirement set formed in step S101 is converted into evidence digest nodes with source, index, summary, and business order, thereby forming the evidence dependency chain required for subsequent gap location and blockchain evidence storage.

[0028] The evidence storage system retrieves business records from the corresponding business system according to the source system and off-chain index rules in the node evidence requirement set. This retrieval process is implemented through internal service interfaces of financial institutions, read-only database views, business message queues, or evidence storage query interfaces. Each query carries the loan business number, evidence digest type, and off-chain index fields. Taking the credit loan disbursement node as an example, the contract signing digest requirement record points to the electronic signature system. The evidence storage system retrieves the contract signing record based on the loan business number, contract version number, and signing serial number. The electronic signature system returns the contract version identifier, signing serial number, signing result status, signing completion time, and signing certificate number. The receiving account confirmation digest requirement record points to the account confirmation system or credit core system. The evidence storage system retrieves the account confirmation record based on the loan business number and account confirmation record number. The source system returns the account confirmation record number, account confirmation result, account confirmation time, and account anonymization identifier. The loan disbursement instruction digest requirement record points to the credit core system. The loan disbursement instruction record is obtained based on the loan transaction number and disbursement instruction number. The core credit system returns the disbursement instruction number, disbursement instruction status, disbursement instruction generation time, and disbursement batch identifier. The payment receipt summary requirement record points to the payment system. The evidence storage system obtains the payment receipt record based on the loan transaction number and payment receipt number. The payment system returns the payment receipt number, payment channel return status, payment completion time, and payment batch identifier. The accounting result summary requirement record points to the accounting system. The evidence storage system obtains the accounting result record based on the loan transaction number and accounting record number. The accounting system returns the accounting record number, accounting processing status, accounting completion time, and accounting batch identifier. These business records correspond one-to-one with the evidence requirement records in the node evidence requirement set, ensuring that each subsequently generated evidence summary can be located to its source system and off-chain index.

[0029] When the source system does not return a business record, returns multiple candidate business records, or the returned record status is still "processing" at the current query time, the evidence storage system does not directly generate an evidence summary based on manual selection. Instead, it performs deterministic processing according to the off-chain index rules in the node evidence requirement set. When no business record is returned, the system retains the position to be obtained and forms a corresponding incomplete dependency edge in the evidence dependency chain. When multiple candidate business records are returned, the system performs uniqueness verification based on the off-chain index field, business record version number, business completion time, and the source system's unique serial number. Only when a unique and valid business record can be determined will a summary be generated; otherwise, a record conflict position to be processed will be formed. When the returned record status is "processing," "revoked," "invalid," or "incomplete," the system decides whether to retain the position to be obtained or exclude auxiliary records according to the necessity identifier of the record required by the evidence requirement. Through this processing, the evidence summary node will not mistakenly enter the closed evidence chain due to asynchronous receipt not arriving, duplicate receipt, supplementary record entry, or incomplete source system status.

[0030] After obtaining business records, the evidence storage system extracts verifiable fields according to the allowed on-chain fields in the corresponding evidence requirements record, and forms a standardized field string with fixed character encoding, fixed field order, and fixed separators. This standardized field string ensures that the same business record can be regenerated in the same way during subsequent verification. Taking contract signing summary as an example, the standardized field string is arranged according to loan business number, evidence summary type, contract version identifier, signing serial number, signing result status, and signing completion time; taking payment receipt summary as an example, the standardized field string is arranged according to loan business number, evidence summary type, payment receipt number, payment channel return status, payment completion time, and payment batch identifier; taking accounting result summary as an example, the standardized field string is arranged according to loan business number, evidence summary type, accounting record number, accounting processing status, accounting completion time, and accounting batch identifier. Field names may differ from those in different source systems; the evidence storage system converts them into standardized field strings under the corresponding evidence summary type according to the off-chain indexing rules and allowed on-chain field range in the node evidence requirements set. For example, the "payment channel serial number" returned by the payment system can be mapped to the payment receipt number field corresponding to the payment receipt summary according to a pre-defined mapping, and the "core entry serial number" returned by the accounting system can be mapped to the entry record number field corresponding to the entry result summary according to a pre-defined mapping. This field entry method is well-suited to credit evidence storage scenarios, enabling summary generation to revolve around the verifiable fields required for the evidence chain at the current node.

[0031] The normalized field string also includes fixed processing rules for null values, time, amount, anonymized fields, and character encoding. For null fields within the allowed range of fields to be uploaded to the chain, the system uses a preset null value identifier to write to the corresponding field position instead of directly deleting the field; for time fields, the system uniformly converts them to time strings with preset time zones and precision; for amount fields, the system uniformly converts them to preset currencies and decimal places; for sensitive fields such as customer names, ID numbers, account numbers, and contact information, the system does not write the original plaintext into the normalized field string, but instead uses anonymized identifiers, field summaries, or off-chain index identifiers returned by the source system to participate in the summary construction, and retains an index in the off-chain index directory that allows controlled retrieval of the original record. The above processing enables the on-chain summary to fix the evidence content and source relationship, while avoiding expanding the scope of original sensitive information uploaded to the chain; during subsequent verification, the original record is only obtained based on the off-chain index under authorized conditions, and the summary is recalculated according to the same normalization rules.

[0032] The evidence digest generation employs the classic form of cryptographic hash functions. The basic form of a hash function in cryptography maps an input message to a fixed-length digest, i.e., a digest identifier is obtained from the message. In this invention, the input message is constructed from the loan business number, the current business node number, the evidence digest type, the off-chain index string, the verifiable field string, and the node requirement binding item. The derivation process is as follows: first, a normalized field string is generated from the source system's business records and the node's evidence requirement set; then, this normalized field string is concatenated with the current node requirement binding item to form the digest input message; finally, the evidence digest is calculated by the cryptographic service module of the evidence storage system. The node requirement binding item is used to bind the evidence digest to the evidence requirement of the current credit node. This is suitable for scenarios where the same business record is referenced by different credit nodes. For example, the same contract signing record can prove the completion of signing at the signing node, or it can serve as pre-loan support at the loan disbursement node.

[0033] ;

[0034] in, Indicates the first The evidence requirement records the generated evidence digest, which is calculated by the cryptographic service module of the evidence storage system. The standard hash algorithm representing the configuration of the evidence storage system is provided by the blockchain evidence storage platform or cryptographic service module; This indicates the loan transaction number, which comes from the loan master table in the core credit business system. This indicates the current business node number, which comes from the node status change record in step S101 and is passed into this step along with the node evidence requirement set; Indicates the first The evidence summary type in the evidence requirement record comes from the node evidence requirement set output in step S101; Indicates the first Each piece of evidence requires a record of the corresponding off-chain index string, which consists of the source system identifier, business record number and evidence digest type in a preset order, and originates from the node evidence requirement set and the business record returned by the source system; This represents the verification field string returned by the source system, whose field range is from the first... This evidence requires limiting the range of fields allowed to be uploaded to the chain in the record; Indicates the first Each piece of evidence requires the node to be bound to an item, which is formed by the source system, the range of fields allowed to be uploaded to the chain, the necessity identifier, and the order within the node according to a preset order; This indicates that strings are concatenated in a preset order. The formula on the right first generates a normalized string message, which is then processed... Then output the summary string on the left. Both input and output are treated as character identifiers in the digital evidence storage system, and the calculation relationship is consistent with the input and output form of the hash function.

[0035] During the generation of a payment receipt summary at a credit loan disbursement node Retrieve loan business number "LN2026010008" Retrieve the loan disbursement node number "PAY_OUT" Retrieve "Payment Receipt Summary" It consists of the payment system identifier "PAY_SYS" and the payment receipt number "PR20260109001". It consists of the payment channel return status "SUCCESS", the payment completion time "2026-01-09T10:35:28", and the payment batch identifier "BATCH07". It consists of the source system "PAY_SYS", the allowed range of fields to be uploaded to the chain "receipt_status_time_batch", the necessity flag "required", and the order within the node "order4". The evidence storage system generates the string "LN2026010008|PAY_OUT|Pay Receipt Summary|PAY_SYS:PR20260109001|SUCCESS:2026-01-09T10:35:28:BATCH07|PAY_SYS:receipt_status_time_batch:required:order4" according to a preset order, and calls the configured hash algorithm to generate a fixed-length hexadecimal digest, which serves as the digest in the payment receipt node. During subsequent verification, the system retrieves the payment receipt record again based on the same off-chain index, generates strings according to the same field order, calculates the digest, and compares it with... Perform a consistency comparison.

[0036] After generating the evidence digest, the evidence storage system creates an evidence digest node for each piece of evidence. The evidence digest node includes at least the evidence digest, evidence digest type, source system, off-chain indexing rules, necessity identifier, intra-node order, digest generation time, and node requirement binding items. The evidence digest originates from the hash calculation result; the evidence digest type, source system, off-chain indexing rules, necessity identifier, and intra-node order come from the node's evidence requirement set; the digest generation time comes from the time source recorded by the evidence storage system during digest generation; and the node requirement binding items come from the corresponding evidence requirement record. When the source system returns a business record, the evidence storage system generates the corresponding evidence digest node; when the source system returns an empty status, the evidence storage system retains the pending position for that evidence digest type based on the node's evidence requirement set. The pending position records the evidence digest type, source system, off-chain indexing rules, necessity identifier, and intra-node order, and is then added to the evidence dependency chain output in this step. Taking the loan disbursement node as an example, if the contract signing record, loan disbursement instruction record, payment receipt record, and deposit result record have been returned, but the receiving account confirmation record returns an empty status, then the contract signing summary node, loan disbursement instruction summary node, payment receipt summary node, and deposit result summary node are generated in the evidence dependency chain. At the same time, the position of the receiving account confirmation summary to be obtained is reserved so that the next step can directly locate the gap.

[0037] The construction of the evidence dependency chain is based on evidence summary nodes and the positions to be acquired, and is grounded in the order within nodes and business support relationships. The order within nodes comes from the node evidence requirement set output in step S101, used to determine the basic arrangement of evidence summary nodes within the same node; the business support relationship comes from the configuration of prerequisite evidence in the pre-set evidence storage rules, used to determine whether a certain evidence summary node supports another evidence summary node. Taking the loan disbursement node as an example, the contract signing summary node and the receiving account confirmation summary node jointly support the loan disbursement instruction summary node, the loan disbursement instruction summary node supports the payment receipt summary node, and the payment receipt summary node supports the accounting result summary node. This dependency relationship corresponds to the process logic in real loan disbursement business where "contract signing and account confirmation form prerequisites for loan disbursement, the loan disbursement instruction triggers payment channel processing, and the payment channel processing result supports the accounting result." For the approval node, the credit authorization summary node supports the credit inquiry result summary node, and the credit inquiry result summary node and the income certificate summary node jointly support the approval opinion summary node; for the collection node, the overdue result summary node supports the notification content summary node, and the notification content summary node supports the delivery result summary node. Thus, the evidence dependency chain can adapt to different credit nodes and is always driven by the node evidence requirement set in step S101.

[0038] To ensure that the supporting relationships between evidence digests themselves possess verification capabilities, the evidence storage system generates dependency edge digests for the dependencies between evidence digest nodes. The dependency edge digest originates from the evidence digest nodes and the business support relationships, representing a further application of the basic form of cryptographic hashing. The derivation process is as follows: First, the preceding and following evidence digests are generated using the previous formula. Then, the dependency relationship type and business rationale between them are obtained from the pre-defined evidence storage rules. Subsequently, the preceding evidence digest, following evidence digest, dependency relationship information, and the binding requirements of both nodes are concatenated into a dependency edge message, and the dependency edge digest is calculated. The logical relationship between this formula and the previous formula is as follows: and It is obtained from the formula for generating evidence summaries. It is generated on this basis and is used to fix the business connection relationship between evidence digest nodes.

[0039] ;

[0040] in, Indicates from the preceding evidence summary node Pointing to the post-evidence digest node The dependency edge summary is calculated by the evidence storage system; Indicates the preceding evidence summary node The corresponding evidence summary comes from the evidence summary node already generated in this step; Indicates the post-evidence summary node The corresponding evidence summary comes from the evidence summary node already generated in this step; Indicates the preceding evidence summary node With post-evidence summary node The dependency relationships and business rationales between them are derived from the business support relationship configuration in the pre-built evidence storage rules; Indicates the preceding evidence summary node The corresponding node requires the binding item, and the evidence requirement record comes from the corresponding node; Indicates the post-evidence summary node The corresponding node requires the binding item, and the evidence requirement record comes from the corresponding node; This indicates that the strings are concatenated in a preset order. The right side of the formula constructs a dependency edge message from the two evidence summaries and the business relationship between them, which is then processed... Then output the dependency edge summary on the left. It is used to identify a verifiable business support edge in the evidence dependency chain.

[0041] When generating a dependency edge in the loan disbursement node that depends on the contract signing summary for the loan disbursement instruction summary, Retrieve the summary value from the contract signing summary node. Retrieve the summary value from the loan disbursement instruction summary node. The clause "Contractual Support: Loan disbursement instructions should be based on the completion of contract signing" is relevant. The node corresponding to the contract signing summary requires the binding item. The node corresponding to the loan disbursement instruction summary requires a bound item. The evidence storage system concatenates the above content in a preset order and then calculates the result. The system then writes this summary into the dependency edge pointing from the contract signing summary node to the loan disbursement instruction summary node. For the "loan disbursement instruction summary dependent on the receiving account confirmation summary," the evidence storage system uses the receiving account confirmation summary as the preceding summary and the loan disbursement instruction summary as the following summary, generating another dependency edge summary in the same manner. Both dependency edges together indicate that the loan disbursement instruction is supported by both contract signing and account confirmation, allowing for the separate assessment of the completeness of the signing and account confirmation support during subsequent gap location.

[0042] When generating dependency edges, the evidence storage system traverses the evidence digest nodes according to the order within each node and reads the pre-configured prerequisite relationship settings in the pre-set evidence storage rules. When a subsequent evidence digest node is configured with a preceding evidence digest node, the system generates a dependency edge between them; when a subsequent evidence digest node is configured with multiple preceding evidence digest nodes, the system generates multiple dependency edges for each, and these multiple dependency edges all point to the subsequent evidence digest node. For necessary evidence requirement records where the source system returns an empty status, the evidence storage system generates incomplete dependency edges based on their pending position. Incomplete dependency edges record the preceding or subsequent evidence digest type, source system, off-chain indexing rules, necessity identifier, order within the node, and business reason. Taking the credit loan disbursement node as an example, the contract signing summary node and the receiving account confirmation summary node point to the disbursement instruction summary node, the disbursement instruction summary node points to the payment receipt summary node, and the payment receipt summary node points to the accounting result summary node. When the receiving account confirmation summary is in a pending state, the system retains the pending position of the receiving account confirmation summary and forms an incomplete dependency edge pointing to the disbursement instruction summary node, so that the next step can identify the gap located in the account confirmation support path.

[0043] After the evidence dependency chain is formed, the evidence storage system performs intra-chain consistency processing around the node evidence requirement set. This processing includes whether the evidence summary node corresponds to the evidence requirement record in the node evidence requirement set, whether the source system of the evidence summary node is consistent with the source system in the evidence requirement record, whether the off-chain index rule of the evidence summary node can locate the source system business record, whether the preceding relationship of the dependent edge comes from the pre-set evidence storage rules, and whether the order within the node is consistent with the direction of the dependent edge. Taking the loan disbursement node as an example, the source system of the payment receipt summary node should be the payment system, and its off-chain index rule should be able to locate the payment receipt number; the preceding node of the payment receipt summary node should be the loan disbursement instruction summary node; and the preceding node of the crediting result summary node should be the payment receipt summary node. After this processing, each evidence summary node in the evidence dependency chain can be traced back to the evidence requirement record output in step S101, and each dependent edge can be traced back to the business support relationship in the pre-set evidence storage rules.

[0044] This step outputs the evidence dependency chain. The evidence dependency chain consists of evidence summary nodes, positions to be acquired, dependency edges, and incomplete dependency edges. An evidence summary node must include at least the evidence summary, evidence summary type, source system, off-chain indexing rules, necessity identifier, intra-node order, summary generation time, and node binding requirements. Positions to be acquired must include at least the evidence summary type, source system, off-chain indexing rules, necessity identifier, and intra-node order. Dependency edges must include at least the preceding evidence summary node, the following evidence summary node, dependency relationship type, business reason, and dependency edge summary. Incomplete dependency edges must include at least the missing evidence summary type, the existing evidence summary node, source system, off-chain indexing rules, business reason, and intra-node order. The next step takes the evidence dependency chain as input, checks the completeness of necessary evidence summary nodes and dependency edges, locates evidence gaps, and binds the corrected evidence summaries to the corresponding gap positions to generate a closed evidence chain.

[0045] Step S103: Locate the evidence gap according to the position to be obtained in the evidence dependency chain, obtain the correction business record to generate a correction evidence summary node, and connect the correction evidence summary node to the evidence dependency chain to generate a closed evidence chain.

[0046] Specifically, the evidence storage system takes the evidence dependency chain output in step S102 as input and fully reads the evidence summary nodes, pending positions, dependent edges, and incomplete dependent edges within it. Evidence summary nodes carry evidence summaries already generated from the source system's business records; pending positions carry necessary evidence summary positions that are yet to be obtained but have been defined by the node evidence requirement set; dependent edges carry established business support relationships; and incomplete dependent edges carry preceding support, subsequent results, or support connections that still need to be completed. The evidence storage system traverses these objects sequentially within the nodes of the evidence dependency chain and matches each pending position with its adjacent incomplete dependent edge to determine the specific location of the gap in the evidence chain. If the preceding end of an incomplete dependent edge is a pending position and the following end is an existing evidence summary node, the gap is located as a preceding support evidence gap; if the preceding end of an incomplete dependent edge is an existing evidence summary node and the following end is a pending position, the gap is located as a subsequent result evidence gap; if both the preceding and following ends have existing evidence summary nodes, but the dependency edge summary between them is yet to be formed, the gap is located as a support connection gap. Taking the credit loan disbursement node as an example, the evidence dependency chain already contains a contract signing summary node, a loan disbursement instruction summary node, a payment receipt summary node, and an account receipt summary node. At the same time, there is a position where the receiving account confirmation summary is yet to be obtained, as well as an incomplete dependency edge pointing from the receiving account confirmation summary to the loan disbursement instruction summary. Based on this, the evidence storage system identifies this position as an account confirmation support gap. This gap indicates that the loan disbursement instruction summary has been generated, but the account confirmation prerequisite support for the loan disbursement instruction in the current node still needs to be completed.

[0047] The evidence storage system generates gap records based on the location of the gap. These gap records are directly derived from the pending position and incomplete dependency edges in the evidence dependency chain, while retaining the source system and off-chain indexing rules required for subsequent acquisition of corrective records. Each gap record includes a gap number, loan business number, current business node number, missing evidence digest type, corresponding source system, off-chain indexing rule, affected dependency type, business reason, necessity identifier, intra-node order, and gap generation time. The gap number is composed of the loan business number, current business node number, missing evidence digest type, and intra-node order in a preset order, used to stably locate the gap within the same loan and the same business node; the missing evidence digest type comes from the pending position; the source system and off-chain indexing rule come from the pending position retained in step S102; the affected dependency type and business reason come from incomplete dependency edges; the necessity identifier and intra-node order use the corresponding fields in the evidence dependency chain of step S102; and the gap generation time comes from the processing log when the evidence storage system generates the gap record. Taking the account confirmation support gap in the loan disbursement node as an example, the gap record can be composed of the loan business number, loan disbursement node number, receiving account confirmation summary, account confirmation system, account confirmation record number, account confirmation support, the loan disbursement instruction should be based on receiving account confirmation as a prerequisite, necessary evidence identifier, and the order within the node. This gap record serves as the location object for subsequent acquisition of supplementary evidence summary, reconnection of dependent edges, and closure binding.

[0048] The evidence storage system retrieves the corrected business records according to the source system and off-chain indexing rules in the gap records. The acquisition path of the corrected business records follows the position to be obtained in the evidence dependency chain, ensuring that the corrected evidence summary and the original evidence require the same source, the same index, and the same field definition. For account confirmation support gaps, the evidence storage system obtains the account confirmation record through the evidence storage query interface of the account confirmation system or the credit core system based on the account confirmation system identifier, loan business number, and account confirmation record number. The account confirmation record may include the account confirmation record number, account confirmation result, account confirmation time, and account anonymization identifier. For payment receipt gaps, the evidence storage system obtains the payment channel receipt record based on the payment system identifier and payment receipt number. For accounting result gaps, the evidence storage system obtains the accounting accounting result based on the accounting system identifier and accounting record number. For delivery result gaps, the evidence storage system obtains the delivery result record based on the notification system or collection system identifier and delivery record number. After the source system returns the corrected business record, the evidence storage system generates a corrected evidence digest according to the generation method of similar evidence digests in step S102. Specifically, it extracts verifiable fields according to the allowed on-chain field range for the corresponding evidence digest type, forms a standardized field string in a fixed field order, and calls the same hash algorithm to generate the corrected evidence digest. After the corrected evidence digest is generated, the evidence storage system converts the original position to be obtained into a corrected evidence digest node. This node includes the corrected evidence digest, evidence digest type, source system, off-chain index rules, necessity identifier, intra-node order, digest generation time, corresponding gap number, and corrected record acquisition time. Taking the loan disbursement node as an example, after the account confirmation system returns the account confirmation record, the evidence storage system generates a receiving account confirmation digest and converts the position to be obtained in the evidence dependency chain into a receiving account confirmation digest node. Simultaneously, it retains the account confirmation support gap number, enabling this corrected node to correspond with the original gap and subsequent reconnection dependency edges.

[0049] If the correction query still fails to retrieve the business record, the source system of the retrieved business record is inconsistent with the gap record, the off-chain index field cannot match the gap record, or the evidence summary type corresponding to the corrected business record is inconsistent with the missing evidence summary type, the evidence storage system will not connect the record to the original evidence dependency chain. Instead, it will keep the corresponding gap unclosed and record the reason for the correction failure. If the same gap retrieves multiple corrected business records at different times, the system will deduplicate them using the gap number, source system, off-chain index rule, and business record version identifier. If a corrected evidence summary has already been generated for the same version, a closed binding summary will not be generated again. When the source system returns a new version and the rules allow for correction replacement, the system will retain the version relationship between the original corrected record and the new corrected record and form a new closed binding summary in a new batch of closure processing. This process ensures that the corrected evidence is not arbitrarily added material, but must be obtained from the original gap's specified source and index, and can explain the correspondence between the corrected record and the original evidence chain position.

[0050] After the supplementary evidence digest node is formed, the evidence storage system reconnects the dependency edges based on the original incomplete dependency edges. For gaps in preceding supporting evidence, the supplementary evidence digest node serves as the preceding evidence digest node, and the existing subsequent evidence digest node serves as the subsequent evidence digest node. The system generates a reconnection dependency edge digest based on the dependency relationship type and business reason in the incomplete dependency edge. For gaps in subsequent result evidence, the existing preceding evidence digest node serves as the preceding evidence digest node, and the supplementary evidence digest node serves as the subsequent evidence digest node. The system generates a reconnection dependency edge digest. For gaps in supporting connection, both the preceding and subsequent evidence digest nodes come from the evidence digest nodes already generated in step S102. The system generates a reconnection dependency edge digest based on the dependency relationship type and business reason between the two. The generation method of the reconnection dependency edge digest follows the dependency edge digest generation logic in step S102, that is, constructing a dependency edge message with the evidence digests of both ends, the dependency relationship type, the business reason, and the binding items required by the nodes of both ends, and the digest is calculated by the cryptographic service module. Taking the account confirmation support gap as an example, the corrected receiving account confirmation summary node is used as the preceding node, and the loan instruction summary node is used as the following node. The dependency relationship type is account confirmation support. The business reason is that the loan instruction should be based on the receiving account confirmation as the preceding basis. The evidence storage system generates a reconnection dependency edge summary from the receiving account confirmation summary node to the loan instruction summary node, and converts the original incomplete dependency edge into a completed dependency edge.

[0051] To establish the correspondence between the fixed gap location, the gap closure object, and the reconnection path, the evidence storage system generates a closure binding digest. The initial source of this digest is the basic form of a hash function in cryptography, mapping the determined input message to a fixed-length digest. In step S102, the hash function has already been used to map the source system's business records to evidence digests and to map the preceding evidence digest, the following evidence digest, and the business support relationship to dependency edge digests. In this step, the hash input is further expanded to include gap location information, a gap closure object digest, a reconnection dependency edge digest, a closure action identifier, and in-situ constraint terms. Gap location information is used to pinpoint the location of the gap within the current chain of evidence dependencies; the gap closure object summary is used to pinpoint the object used in this closure. When the gap is a preceding supporting evidence gap or a subsequent result evidence gap, the object is a corrective evidence summary; when the gap is a supporting connection gap, the object is a newly generated reconnection dependency edge summary; the reconnection dependency edge summary is used to pinpoint the supporting relationship after the corrected node or reconnection relationship is rejoined to the original chain; the closure action identifier is used to pinpoint the action process of obtaining the corrected record and the closure processing; the in-situ constraint term is used to pinpoint the necessity, intra-node order, and dependency type of the closure object within the current credit node. Thus, the closure binding summary can bind the "original gap, closure object, and reconnection path" into a verifiable closure record.

[0052] ;

[0053] in, Indicates the first The closing binding summary of each evidence gap is calculated by the evidence storage system and written into the closed evidence chain; The standard hash algorithm representing the configuration of the evidence storage system is provided by the blockchain evidence storage platform or cryptographic service module; Indicates the first The gap location information for each evidence gap consists of the loan business number, the current business node number, the type of missing evidence summary, the source system, and the order within the node, arranged in a preset order. It comes from the position to be obtained and the incomplete dependency edge in the evidence dependency chain. Indicates the first Summary of gap closure objects for each evidentiary gap, when the preceding supporting evidence gap or the subsequent outcome evidence gap is closed. Take the corrected evidence summary obtained according to the evidence summary generation method in step S102. When the support connection gap is closed... Retrieve the summary of the newly generated reconnected dependency edges; This represents the reconnection dependency edge summary between the closed object and its preceding evidence summary node. It comes from the reconnection calculation of the original incomplete dependency edges in this step. If the gap is located at the head of the current node chain, then the preset head of the chain identifier is filled in. This represents the reconnection dependency edge summary between the closed object and its subsequent evidence summary node. It comes from the reconnection calculation of the original incomplete dependency edges in this step. If the gap is located at the end of the current node chain, a preset chain end identifier is filled in. The indicator for the closing action consists of the gap number, the time the correction record was obtained, and the closing time, arranged in a preset order, and comes from the gap record and the closing processing log. This represents an in-situ constraint term, which consists of a necessity identifier, the order within the node, and the types of affected dependencies in a preset order, originating from gap records and incomplete dependency edges; This indicates that strings are concatenated in a preset order. The right side of the formula first forms a closed binding message, which is then processed... The calculated closed-binding summary is output on the left. Each input item is a pre-encoded string identifier or digest string. The hash function receives the byte string and outputs the digest string. The input construction and output results conform to the digest processing logic in the digital evidence storage system.

[0054] Taking the account confirmation support gap in the credit loan disbursement process as an example, It consists of the loan business number "LN2026010008", the loan disbursement node number "PAY_OUT", the missing evidence digest type "receiving account confirmation digest", the source system "ACCOUNT_SYS", and the intra-node order "order2". After the source system returns the account confirmation record, the evidence storage system obtains the receiving account confirmation digest according to the digest generation method in step S102, and uses this digest as... The account confirmation summary serves as a prerequisite for the loan disbursement instruction. If it is located at the head of the chain in the current node, then... Enter the preset chain head identifier. Retrieve the reconnection dependency edge summary from the receiving account confirmation summary node to the loan disbursement instruction summary node; It consists of the account confirmation gap number, the time the correction record was obtained, and the closing time; It consists of the necessity identifier "required", the intra-node order "order2", and the dependency type "account confirmation support". The evidence storage system concatenates the above content into a closed binding message in a preset order, such as "LN2026010008:PAY_OUT:Payment Account Confirmation Summary:ACCOUNT_SYS:order2|Payment Account Confirmation Summary|CHAIN_START|E_m^+|Gap Number:Correction Record Acquisition Time:Closing Time|required:order2:Account Confirmation Support", and calls the cryptographic service module to calculate the closed binding summary. For the supporting connection gap, the preceding evidence digest node and the following evidence digest node already exist. The evidence storage system generates a reconnection dependency edge digest based on the dependency relationship type between them and the business reason, and uses this reconnection dependency edge digest as... Participate in the calculation of the closed-loop binding digest. During subsequent review, the system re-obtains the corrected business record and recalculates the corrected evidence digest according to the off-chain index rules, or recalculates the reconnection dependency edge digest based on the evidence digest nodes at both ends and the business reason, and then recalculates it in the same input order. And perform a consistency comparison with the closed binding summary stored in the closed evidence chain.

[0055] When multiple gaps exist within the same credit node, the evidence storage system generates closed binding digests for each gap sequentially according to the node's internal order, and generates a closed chain digest for the current node. Before generating the closed chain digest, the evidence storage system first generates a basic digest of the original evidence dependency chain based on the evidence dependency chain output in step S102. The basic digest of the original evidence dependency chain is obtained by concatenating the evidence digest node digest, the position identifier to be obtained, the dependency edge digest, and the incomplete dependency edge identifier from the evidence dependency chain in step S102 according to the node's internal order, and then performing hash calculation. It is used to identify the evidence dependency chain structure before correction. The initial source of the closed chain digest is also the basic form of a cryptographic hash function, and its input consists of the basic digest of the original evidence dependency chain, the closed binding digests of each gap, and the closing order item of the current node. Each closed binding digest is used to identify the closing process of each gap, and the closing order item of the current node is used to fix the processing order of multiple gaps in the current business node. There is a progressive relationship between this summary and the closed binding summary: first, a closed binding summary is generated for each gap, and then all the closed binding summaries are calculated together with the original evidence dependency chain base summary in the order within the node to calculate the closed chain summary, thereby fixing the evidence chain structure after the current node is closed as a whole.

[0056] When the evidence dependency chain output in step S102 has no necessary evidence gaps and all dependent edges are complete, the evidence storage system still generates the original evidence dependency chain basic summary and records the current node's closure sequence item as a gap-free closed state, enabling subsequent closed-loop evidence packages to prove that the node had completed the necessary evidence verification during generation. When there are necessary evidence gaps but the correction fails or the node is still pending, the system does not mark the node as a complete closed node, but instead forms an unclosed evidence chain with an unclosed gap directory for subsequent correction or manual authorization review. Only when the necessary evidence summary node and necessary dependent edges are closed, and both the closed binding summary and the closed chain summary can be recalculated, will the system output the node as a closed evidence chain. Through this process, the closed chain summary will not obscure the still-unfilled necessary evidence gaps, avoiding the mistaken uploading of incomplete evidence chains as complete evidence packages.

[0057] ;

[0058] in, This represents the closed-chain summary of the current credit business node, which is calculated by the evidence storage system and written into the closed evidence chain. The standard hash algorithm representing the configuration of the evidence storage system is provided by the blockchain evidence storage platform or cryptographic service module; The original evidence dependency chain basic summary is calculated in real time by the evidence dependency chain output by the evidence storage system based on step S102. Specifically, it is formed by concatenating the evidence summary node summary, the location identifier to be obtained, the dependency edge summary, and the incomplete dependency edge identifier in the order within the node and then performing hash calculation. to Indicates the first to the second in the current business node. The closed binding digests corresponding to each gap are all generated by the aforementioned closed binding digest formula; This represents the current node closure sequence item, which consists of the current business node number, closure processing batch, and gap closure sequence in a preset order, and comes from the closure processing log of the evidence storage system. This indicates that strings are concatenated in a preset order. The right side of the formula forms the closed chain of messages for the current node, after... Output the summary of the closed chain on the left after calculation. This formula logically uses the various formulas generated by the previous formula. The results of multiple gap closures are aggregated into a single overall closure identifier for the current business node.

[0059] Taking the case where the loan disbursement node has both a gap in the confirmation of the receiving account and a gap in the receipt result as an example, the evidence storage system first calculates the evidence dependency chain of the loan disbursement node based on the output of step S102. ,Should The loan disbursement node is formed by the following nodes in sequence: contract signing summary node, pending receipt account confirmation summary, loan disbursement instruction summary node, payment receipt summary node, pending deposit result location, completed dependency edges, and incomplete dependency edges. Subsequently, the evidence storage system generates a closed-loop binding summary for the receipt account confirmation gap. Generate a closed-loop binding summary for gaps in the accounting results. ; It consists of the loan disbursement node number "PAY_OUT", the closing batch number "CLOSE_BATCH_01", and the gap closing sequence "order2-order5". The evidence storage system will... , , and The messages are concatenated into a closed chain for the current node according to a preset order, and the cryptographic service module is invoked to calculate the closed chain digest. This summary is saved along with the closed chain of evidence, allowing the next step to directly reference the overall closure result of the current node when generating the closed-loop evidence package.

[0060] After the evidence storage system completes gap filling, dependent edge reconnection, closure binding summary, and closure chain summary generation, a closed evidence chain is formed. The closed evidence chain inherits the original evidence summary node, original dependent edge, and completed dependent edge summary from the evidence dependency chain in step S102. It converts the position to be obtained into a corrected evidence summary node, converts incomplete dependent edges into reconnected dependent edges, and adds gap records, closure binding summaries, and closure chain summaries. For paths in the original evidence dependency chain that already have complete supporting relationships, the closed evidence chain retains the original evidence summary node and original dependent edge; for corrected paths, the closed evidence chain records the original gap position, corrected evidence summary node, reconnected dependent edge, closure binding summary, and corresponding off-chain index rules; for nodes with multiple gaps, the closed evidence chain records the closing order of each gap according to the node's internal order and fixes the overall closed structure through the closure chain summary. Taking the credit loan disbursement node as an example, the closed evidence chain can form a complete chain where the contract signing summary node and the receiving account confirmation summary node both point to the loan disbursement instruction summary node, the loan disbursement instruction summary node points to the payment receipt summary node, and the payment receipt summary node points to the accounting result summary node. If the receiving account confirmation summary node is obtained through correction, then this node is associated with the account confirmation gap record, the reconnection dependency edge summary, and the closure binding summary, and the entire loan disbursement node is associated with the closed chain summary.

[0061] After generating a closed evidence chain, the evidence storage system performs an in-chain closure verification. The verification is performed according to the node order of the evidence dependency chain, specifically including whether all necessary evidence summary nodes have evidence summaries, whether all necessary dependent edges have formed dependent edge summaries, whether the evidence summary type of the corrected evidence summary node is consistent with the original gap record, whether the source system of the corrected evidence summary node is consistent with the original gap record, whether the off-chain index rules of the corrected evidence summary node can locate the corrected business record, whether the closure binding summary can be recalculated from the gap location information, the corrected evidence summary, the reconnected dependent edge summary, the closure action identifier, and the in-situ constraint item, and whether the closed chain summary can be recalculated from the original evidence dependency chain basic summary, each closure binding summary, and the current node closure sequence item. Taking the loan disbursement node as an example, the evidence digest type of the receiving account confirmation digest node corresponds to the receiving account confirmation digest in the account confirmation gap record, the source system corresponds to the account confirmation system, the off-chain index rule locates the account confirmation record number, the dependent edge of the receiving account confirmation digest node pointing to the loan instruction digest node has a reconnection dependent edge digest, the closed binding digest corresponding to the account confirmation gap can be recalculated according to the above formula, and the closed chain digest of the entire loan disbursement node can be recalculated according to the closing order within the node. After this verification, the closed evidence chain enters the next step of closed-loop evidence package generation and blockchain storage process.

[0062] This step outputs a closed evidence chain. The closed evidence chain consists of the original evidence summary node, the corrected evidence summary node, the original dependency edge, the reconnection dependency edge, the gap record, the closure binding summary, and the closed chain summary. The original evidence summary node and the original dependency edge come from the evidence dependency chain output in step S102; the corrected evidence summary node comes from the corrected business record obtained in this step according to the source system and off-chain index rules in the gap record; the reconnection dependency edge comes from the dependency relationship regenerated in this step based on the original incomplete dependency edge; the gap record comes from the position to be obtained and the incomplete dependency edge in the evidence dependency chain; the closure binding summary comes from the gap location information, the gap closure object summary, the reconnection dependency edge summary, the closure action identifier, and the in-situ constraint item; the closed chain summary comes from the original evidence dependency chain basic summary, each closure binding summary, and the current node closure order item, which are calculated in real-time based on the evidence dependency chain in step S102. The next step takes the closed evidence chain as input, extracts the closed evidence path, evidence summary, gap closure record, closed chain summary, and off-chain index information, generates a closed-loop evidence package, and performs blockchain storage.

[0063] Step S104: Generate a closed-loop evidence package based on the closed evidence chain, and write the evidence package verification summary of the closed-loop evidence package into the blockchain to generate an on-chain verification index.

[0064] Specifically, the evidence storage system takes the closed evidence chain output in step S103 as input, reads the original evidence summary node, the corrected evidence summary node, the original dependency edge, the reconnection dependency edge, the gap record, the closure binding summary, and the closed chain summary from the closed evidence chain, and organizes the above content into a closed-loop evidence package for the current credit business node. The original evidence summary node represents the business evidence that has been obtained from the source system and whose summary has been generated in step S102. The corrected evidence summary node represents the corrected evidence obtained in step S103 to address the gap and reconnect the original chain. The original dependency edge and the reconnection dependency edge together represent the business support relationship between the evidence summary nodes. The gap record represents the position that was previously to be filled in the evidence chain. The closure binding summary represents the binding result between each gap and the corresponding corrected evidence summary and reconnection path. The closed chain summary represents the evidence chain structure after the current business node is closed. The evidence storage system extracts the valid path in the closed evidence chain according to the current business node number and the order within the node, so that the output result includes both the already formed evidence summary and the corrected evidence node and the gap closure process. Taking a credit loan disbursement node as an example, the closed evidence chain can include a contract signing summary node, a receiving account confirmation summary node, a disbursement instruction summary node, a payment receipt summary node, and a payment result summary node. It also includes dependency edges from the contract signing summary node to the disbursement instruction summary node, reconnection dependency edges from the receiving account confirmation summary node to the disbursement instruction summary node, dependency edges from the disbursement instruction summary node to the payment receipt summary node, and dependency edges from the payment receipt summary node to the payment result summary node. When the receiving account confirmation summary node is obtained through correction in step S103, the evidence storage system includes the corresponding account confirmation gap record, correction evidence summary, reconnection dependency edge summary, and closure binding summary into the evidence package of the current node, enabling the evidence package of the disbursement node to present a complete relationship of "original chain, gap position, correction node, and closure result."

[0065] The evidence storage system then generates an evidence package directory according to the node order in the closed evidence chain. The evidence package directory consists of an evidence digest node directory, a dependency edge directory, a gap closure directory, and an off-chain index directory. The evidence digest node directory records the original evidence digest node and the corrected evidence digest node item by item. Directory entries include the evidence digest, evidence digest type, source system, off-chain index rule, necessity identifier, node order, and digest generation time. The evidence digest comes from the digest calculation result of step S102 or step S103. The evidence digest type, source system, off-chain index rule, necessity identifier, and node order follow the node fields in the closed evidence chain. The digest generation time comes from the evidence storage system's time source when the corresponding digest was generated. The dependency edge directory records the original dependency edge and the reconnected dependency edge item by item. Directory entries include the preceding evidence digest node, the following evidence digest node, dependency relationship type, business reason, and dependency edge digest. The dependency relationship type and business reason come from the business support relationship configuration used in step S102 or step S103. The dependency edge digest comes from the hash calculation result of the dependency edge message in step S102 or step S103. The gap closure directory records the gap records and closure binding summaries generated in step S103 item by item. Directory entries include the gap number, missing evidence summary type, corrected evidence summary, reconnection dependency edge summary, closure binding summary, and closure time. The off-chain index directory records the source system identifier and off-chain index rules corresponding to each evidence summary node, used for subsequent retrieval of corresponding business records from the electronic signature system, account confirmation system, credit core system, payment system, accounting system, notification system, or collection system. Taking the loan disbursement node as an example, the contract signing summary node directory entry points to the contract signing record index in the electronic signature system; the receiving account confirmation summary node directory entry points to the account confirmation record index in the account confirmation system; the loan disbursement instruction summary node directory entry points to the loan disbursement instruction record index in the credit core system; the payment receipt summary node directory entry points to the payment receipt record index in the payment system; and the accounting result summary node directory entry points to the accounting record index. These directory entries are saved in the order within the node, enabling subsequent verifiers to reconstruct the closed evidence path of the current node along the evidence package directory.

[0066] After the evidence package directory is formed, the evidence storage system generates a closed-loop evidence package. The closed-loop evidence package includes an evidence package number, loan transaction number, current business node number, evidence summary node directory, dependency edge directory, gap closure directory, closed chain summary, off-chain index directory, and generation time. The evidence package number is composed of the loan transaction number, current business node number, and generation batch in a preset order, used to identify the current closed-loop evidence package for the current credit node; the loan transaction number comes from the evidence summary node in the closed evidence chain; the current business node number comes from the gap location information and closed chain summary generation record in the closed evidence chain; the evidence summary node directory, dependency edge directory, and gap closure directory are all converted from the corresponding objects in the closed evidence chain; the closed chain summary comes from the summary result of the overall closed structure of the current business node in step S103; the off-chain index directory comes from the off-chain index rules in each evidence summary node; and the generation time comes from the time source when the evidence storage system forms the closed-loop evidence package. For the loan disbursement stage, the closed-loop evidence package provides a closed-loop proof of the current loan process, from contract signing, account confirmation, loan disbursement instruction, payment receipt to the final payment. For the collection stage, the closed-loop evidence package provides a closed-loop proof of the overdue payment result, notification content, notification sending record, and delivery result. For the settlement stage, the closed-loop evidence package provides a closed-loop proof of the repayment result, settlement calculation result, settlement proof generation record, and archiving record. Through this cataloging process, the closed-loop evidence package can output structured evidence around a credit business node, rather than simply exporting a collection of raw files from the source system.

[0067] The evidence storage system generates an evidence package verification digest for the closed-loop evidence package. The initial source of this digest is the basic form of a hash function in cryptography, which maps the determined input message to a fixed-length digest. In step S102, the hash function is used to map the source system business records to evidence digests, and to map the preceding evidence digest, the following evidence digest, and the business support relationship to dependency edge digests. In step S103, the hash function is used to map the gap location information, the gap closure object digest, and the reconnection path to the closure binding digest, and to map the original evidence dependency chain basic digest and each closure binding digest to the closure chain digest. In this step, the hash input is further expanded to include the loan business number, the current business node number, the closure chain digest, the gap closure set string, the evidence package directory index string, and the certificate issuance action identifier, which are used to fix the correspondence between the final output closed-loop evidence package and the on-chain evidence storage object. The gap closure set string is not a new independent evidence object, but is formed by concatenating all the closed binding summaries output in step S103 according to the order within the nodes; the evidence package directory index string is formed by concatenating the evidence summary node directory, dependent edge directory, gap closure directory, and off-chain index directory generated in this step according to the order within the nodes. The derivation process is as follows: first, step S102 fixes the business records and their supporting relationships; then, step S103 fixes the gap closure process and the overall closed structure of the current node; finally, this step combines the results of the closed evidence chain organization and the certificate issuance action information into an evidence package verification message, and calculates the evidence package verification summary.

[0068] ;

[0069] in, The evidence package verification digest, representing the closed-loop evidence package, is calculated by the evidence storage system and used as the core digest for on-chain evidence storage. The standard hash algorithm representing the configuration of the evidence storage system is provided by the blockchain evidence storage platform or cryptographic service module; This indicates the loan transaction number, which comes from the evidence digest node in the closed chain of evidence. This indicates the current business node number, derived from gap location information and node closure records in the closed evidence chain; The closed chain summary generated in step S103 is used to identify the evidence chain structure after the current business node is completely closed. This represents the set of gap closures, and is a summary of all closure bindings output in step S103. to Formed by splicing together the nodes in the order they are connected; This represents the evidence package directory index string, which is formed by concatenating the evidence summary node directory, dependency edge directory, gap closure directory, and off-chain index directory in the order within the node, and comes from the evidence package directory generated in this step. The certificate issuance action identifier consists of the evidence package number, generation time, evidence storage request number, and evidence storage system number in a preset order, and comes from the processing log when the evidence storage system generates the closed-loop evidence package and initiates on-chain evidence storage. This indicates that the strings are concatenated in a preset order. The right side of the formula first generates an evidence package verification message, which is then processed... The output after calculation is the evidence package verification summary on the left. Each input item is a digest string, a number string, a directory index string, or an action identifier string. It can be converted into a byte string using a unified character encoding and then input into a hash algorithm. The output result is a digest string, which is suitable for deterministic verification in blockchain evidence storage.

[0070] Taking the credit loan disbursement stage as an example, Retrieve loan business number "LN2026010008" Retrieve the loan disbursement node number "PAY_OUT" Take the summary of the closed chain of the loan disbursement node generated in step S103; if the loan disbursement node has gaps in the confirmation of the receiving account and gaps in the crediting result, then The receiving account confirms the closed binding summary corresponding to the gap. Closed binding summary corresponding to the gap in the accounting results Formed by splicing together the nodes in the order they are connected; The document is formed by concatenating the following nodes in the order of their respective nodes: Contract Signing Summary Node Directory, Receiving Account Confirmation Summary Node Directory, Loan Instruction Summary Node Directory, Payment Receipt Summary Node Directory, Account Received Summary Node Directory, Dependency Edge Directory, Gap Closure Directory, and Off-Chain Index Directory. The evidence package consists of the evidence package number "LN2026010008_PAY_OUT_PKG01", the generation time "2026-01-09T10:42:30", the evidence storage request number "REQ202601090001", and the evidence storage system number "EVID_SYS_01". The evidence storage system concatenates the above content in a preset order to form the evidence package verification message and calls the cryptographic service module to calculate the evidence package verification digest. During subsequent verification, the system rereads the evidence digest nodes, dependency edges, gap closure records, and off-chain index directory based on the closed-loop evidence package directory, and regenerates them in the same order. and , and then combine , , and Recalculation The consistency of the evidence package verification digest stored on the chain is compared.

[0071] After the evidence package verification digest is generated, the evidence storage system constructs a blockchain evidence storage request. The blockchain evidence storage request includes the evidence package verification digest, closed-chain digest, evidence package number, loan business number, current business node number, off-chain index directory digest, gap closure set string, generation time, and evidence storage system signature. The evidence package verification digest comes from the aforementioned calculation results; the closed-chain digest comes from the closed evidence chain output in step S103; the evidence package number comes from the closed-loop evidence package; the loan business number and current business node number come from the closed evidence chain; the off-chain index directory digest is generated by concatenating the off-chain index directory generated in this step according to the node order and inputting it into the standard hash algorithm configured by the evidence storage system, used for subsequent location of off-chain business records and verification that the off-chain index in the evidence package directory has not been replaced; the gap closure set string is formed by concatenating all closed binding digests output in step S103 according to the node order; the generation time comes from the generation time of the closed-loop evidence package; the evidence storage system signature is formed by the evidence storage system using the institution's private key to digitally sign the core fields of the evidence storage request, and the blockchain node verifies the request source through the institution's public key. After the evidence storage request is sent to the blockchain evidence storage platform, the blockchain nodes verify the request format, signature, business node number, and integrity of the digest field. If the verification is successful, the evidence storage request is written into the blockchain ledger, and an on-chain transaction number, block height or block number and blockchain timestamp are generated.

[0072] If the blockchain evidence storage platform returns a signature verification failure, a missing digest field, a mismatch in the business node number, an on-chain write timeout, or a record-keeping failure, the evidence storage system will not mark the closed-loop evidence package as having been uploaded to the blockchain. Instead, it will retain the pending upload status, the reason for failure, and the number of this evidence storage request in the closed-loop evidence package, and will allow verification of the evidence package digest without changing it. Under the premise of re-initiating the on-chain evidence storage request for the same evidence package. If the content of the closed evidence chain changes and re-issuance of evidence is required, the system generates a new evidence package number and an issuance action identifier. Instead of reusing the previously generated evidence package verification digest, it recalculates the evidence package verification digest. In this way, on-chain failure retries and changes to the evidence package content can be distinguished, avoiding the situation where the same evidence package number corresponds to multiple different verification digests, or different evidence package contents mistakenly use the same on-chain verification index.

[0073] After the blockchain ledger is completed, the evidence storage system writes the on-chain transaction number, block height or block number, blockchain timestamp, evidence storage platform identifier, and evidence package verification summary back to the closed-loop evidence package, forming a closed-loop evidence package with an on-chain verification index. The on-chain verification index includes the on-chain transaction number, block height or block number, blockchain timestamp, evidence package verification summary, and evidence storage platform identifier. Taking a loan disbursement node as an example, the closed-loop evidence package stores the evidence package number, loan disbursement node number, contract signing summary directory, receiving account confirmation summary directory, loan disbursement instruction summary directory, payment receipt summary directory, deposit result summary directory, dependent edge directory, gap closure directory, closed chain summary, evidence package verification summary, on-chain transaction number, and off-chain index directory. When auditors or business reviewers verify loan disbursement nodes, they can read the evidence package verification summary from the blockchain ledger based on the on-chain transaction number, and read the business records from the corresponding source system according to the closed-loop evidence package directory and off-chain index rules. They can then recalculate the evidence summary, dependency edge summary, closed binding summary, closed chain summary, and evidence package verification summary to verify the consistency between the current closed-loop evidence package and the on-chain evidence content.

[0074] When the on-chain verification index is written back, the evidence storage system simultaneously records the on-chain write-back time and the write-back verification result. If the on-chain transaction number already exists in the local closed-loop evidence package but the corresponding transaction cannot be found in the blockchain ledger, or if the verification summary of the evidence package read on-chain does not match the one in the local closed-loop evidence package... If there is an inconsistency, the system marks the evidence package as an on-chain verification anomaly and prohibits it from being output as a completed certification result. Only when the evidence package verification summary in the local closed-loop evidence package, the evidence package verification summary in the blockchain ledger, and the transaction information in the on-chain verification index can they correspond to each other, will the closed-loop evidence package enter the archiving, auditing, regulatory retrieval, or judicial evidence presentation stages.

[0075] Before outputting the closed-loop evidence package, the evidence storage system performs a certificate issuance consistency processing. This consistency processing is performed sequentially within the nodes of the closed evidence chain, checking whether the evidence package directory covers all original evidence summary nodes and corrected evidence summary nodes, whether the dependency edge directory covers all original dependency edges and reconnected dependency edges, whether the gap closure directory covers all gap records and closure binding summaries, whether the closed chain summary is consistent with the output of step S103, and whether the evidence package verification summary can be recalculated from the loan business number, current business node number, closed chain summary, gap closure set string, evidence package directory index string, and certificate issuance action identifier. Taking the loan disbursement node as an example, the system verifies that the contract signing summary node, the receiving account confirmation summary node, the loan disbursement instruction summary node, the payment receipt summary node, and the deposit result summary node are all included in the evidence package directory; it verifies that the closed binding summary corresponding to the account confirmation gap is included in the gap closure directory; it verifies that the reconnection dependency edge pointing from the receiving account confirmation summary node to the loan disbursement instruction summary node is included in the dependency edge directory; it verifies that the closed chain summary is consistent with the loan disbursement node closed chain summary output in step S103; and it verifies that the evidence package verification summary can be recalculated according to the aforementioned formula. After this processing, the closed-loop evidence package has an on-chain verification index and an off-chain retrieval index, and enters the archiving, auditing, regulatory retrieval, or judicial evidence presentation stages.

[0076] This step outputs a closed-loop evidence package and an on-chain verification index. The closed-loop evidence package consists of an evidence package number, loan business number, current business node number, evidence summary node directory, dependency edge directory, gap closure directory, closed chain summary, evidence package verification summary, off-chain index directory, and generation time. The evidence summary node directory, dependency edge directory, gap closure directory, and closed chain summary all originate from the closed evidence chain output in step S103. The evidence package verification summary is calculated in this step based on the closed evidence chain and the issuance action information. The on-chain verification index consists of an on-chain transaction number, block height or block number, blockchain timestamp, evidence package verification summary, and evidence storage platform identifier. The on-chain transaction number, block height or block number, and blockchain timestamp originate from the accounting results of the blockchain evidence storage platform. The evidence package verification summary originates from the calculation results of this step, and the evidence storage platform identifier originates from the configuration of the blockchain evidence storage platform. Through this output, the closed evidence chain of the credit business node is transformed into a closed-loop evidence package that can be retrieved, verified, and validated on-chain.

[0077] See Figure 2 , Figure 2 This invention provides a structural block diagram of a blockchain-based system for constructing a chain of evidence for the entire credit process. The system includes: The node rule invocation module is used to obtain the node status change records of the current credit business node and invoke the preset evidence storage rules to generate the node evidence requirement set; The dependency chain construction module is used to obtain business records from the source system based on the node evidence requirement set to generate evidence summary nodes, and to construct an evidence dependency chain based on the business support relationship; the evidence dependency chain includes the evidence summary nodes and the location to be obtained; The closed evidence chain generation module is used to locate the evidence gap according to the position to be obtained in the evidence dependency chain, obtain the correction business record to generate the correction evidence summary node, and connect the correction evidence summary node to the evidence dependency chain to generate a closed evidence chain. The blockchain evidence storage module is used to generate a closed-loop evidence package based on the closed evidence chain, and write the evidence package verification summary of the closed-loop evidence package into the blockchain to generate an on-chain verification index.

[0078] It is worth noting that the specific workflow of the blockchain-based credit full-process evidence chain construction system provided in this embodiment is the same as that of the blockchain-based credit full-process evidence chain construction method described in the above embodiments, and will not be repeated here.

[0079] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A method for constructing a blockchain-based evidence chain for the entire credit process, characterized in that: include: Obtain the node status change records of the current credit business node, and call the pre-set evidence storage rules to generate the node evidence requirement set; Evidence summary nodes are generated from business records obtained from the source system based on the node evidence requirement set, and an evidence dependency chain is constructed based on the business support relationship; the evidence dependency chain includes the evidence summary nodes and the location to be obtained; Based on the location to be obtained in the evidence dependency chain, locate the evidence gap, obtain the correction business record to generate a correction evidence summary node, and connect the correction evidence summary node to the evidence dependency chain to generate a closed evidence chain. A closed-loop evidence package is generated based on the closed evidence chain, and the evidence package verification summary of the closed-loop evidence package is written into the blockchain to generate an on-chain verification index.

2. The method for constructing a blockchain-based evidence chain for the entire credit process as described in claim 1, characterized in that, The step of generating evidence digest nodes from business records obtained from the source system based on the node evidence requirement set includes: The business record is obtained from the source system according to the evidence requirement record in the node evidence requirement set; the evidence requirement record includes the evidence digest type, the source system, off-chain indexing rules, allowed on-chain field range, necessity identifier, and intra-node order; Based on the range of allowed on-chain fields, extract the verification fields to generate a normalized field string; The evidence digest node is generated by hashing the normalized field string.

3. The method for constructing a blockchain-based evidence chain for the entire credit process as described in claim 2, characterized in that, The construction of the evidence dependency chain based on business support relationships includes: Generate a dependency edge summary based on the node order and the business support relationship; Construct the evidence dependency chain; the evidence dependency chain includes the evidence summary node, the position to be obtained, the dependency edge, and the incomplete dependency edge; the dependency edge includes the dependency edge summary.

4. The method for constructing a blockchain-based evidence chain for the entire credit process as described in claim 3, characterized in that, The step of locating the evidence gap based on the position to be obtained in the evidence dependency chain includes: Traverse the positions to be obtained and the incomplete dependency edges in the evidence dependency chain; When the preceding end of the incomplete dependency edge is the position to be obtained and the following end is the evidence summary node, the evidence gap is determined to be a preceding support evidence gap. When the preceding end of the incomplete dependency edge is the evidence digest node and the following end is the position to be obtained, the evidence gap is determined to be a post-result evidence gap; When both the front end and the back end are evidence digest nodes and the dependency edge digest is yet to be formed, the evidence gap is determined to be a support connection gap.

5. The method for constructing a blockchain-based evidence chain for the entire credit process as described in claim 4, characterized in that, The step of obtaining the correction business record to generate a correction evidence summary node, and connecting the correction evidence summary node to the evidence dependency chain to generate a closed evidence chain includes: A gap record is generated based on the evidence gap; the gap record includes gap number, loan business number, current business node number, missing evidence summary type, source system, off-chain indexing rule, affected dependency type, business reason, necessity identifier, intra-node order, and gap generation time; The correction business record is obtained based on the source system and the off-chain indexing rule in the gap record; Hash the correction records to generate a correction evidence digest; Convert the location to be obtained into the corrected evidence summary node; Generate a summary of reconnection dependency edges based on the incomplete dependency edges; Based on the gap location information, the gap closure object summary, the reconnection dependency edge summary, the closure action identifier, and the in-situ constraint item, a closure binding summary is generated; Based on the original evidence dependency chain basic summary, the closed binding summary, and the current node closure sequence item, a closed chain summary is generated to obtain the closed evidence chain.

6. The method for constructing a blockchain-based evidence chain for the entire credit process as described in claim 5, characterized in that, The step of generating a closed-loop evidence package based on the closed chain of evidence includes: Extract valid paths from the closed evidence chain to generate an evidence package directory; the evidence package directory includes an evidence digest node directory, a dependency edge directory, a gap closure directory, and an off-chain index directory; Generate the closed-loop evidence package; the closed-loop evidence package includes evidence package number, loan business number, current business node number, evidence summary node directory, dependent edge directory, gap closure directory, closed chain summary, off-chain index directory and generation time.

7. The method for constructing a blockchain-based evidence chain for the entire credit process as described in claim 6, characterized in that, The step of writing the evidence package verification digest of the closed-loop evidence package into the blockchain to generate an on-chain verification index includes: Based on the loan business number, the current business node number, the closed chain digest, the gap closure set string, the evidence package directory index string, and the certificate issuance action identifier, a hash calculation is performed to obtain the evidence package verification digest; Construct a blockchain evidence storage request; the blockchain evidence storage request includes the evidence package verification digest, the closed chain digest, the evidence package number, the loan business number, the current business node number, the off-chain index directory digest, the gap closure set string, the generation time, and the evidence storage system signature; The blockchain evidence storage request is sent to the blockchain evidence storage platform, and the on-chain transaction number and blockchain timestamp returned by the blockchain evidence storage platform are received. The on-chain verification index is generated based on the on-chain transaction number, block height, blockchain timestamp, evidence package verification digest, and evidence storage platform identifier.

8. The method for constructing a blockchain-based evidence chain for the entire credit process as described in claim 2, characterized in that, The step of extracting verification fields and generating a normalized field string based on the allowed range of on-chain fields includes: The verification fields are arranged according to fixed character encoding, fixed field order, and fixed separation method; For null values ​​in the verification fields, a preset null value identifier is written to the corresponding field position; The time field in the verification field is uniformly converted into a time string with a preset time zone and precision. The amount field in the verification field is standardized to a preset currency and decimal places. For sensitive fields in the verification fields, the de-identification identifier returned by the source system is used to participate in the digest construction to obtain the normalized field string.

9. The method for constructing a blockchain-based evidence chain for the entire credit process as described in claim 1, characterized in that, The step of generating a node evidence requirement set by invoking pre-set evidence storage rules includes: Perform a consistency check based on the loan business number, business node number, and loan business type; After verification, the pre-set evidence storage rules are read using the business node number as the primary condition, and the rule entries are filtered using the loan business type as the secondary condition. Evidence requirements are generated and recorded according to the aforementioned rule entries; The method of recording the evidence requirement is determined based on the necessity markers in the rule entries; The evidence requirement records are arranged according to the node order in the pre-set evidence storage rules to generate the node evidence requirement set.

10. A blockchain-based system for constructing a chain of evidence for the entire credit process, characterized in that: include: The node rule invocation module is used to obtain the node status change records of the current credit business node and invoke the preset evidence storage rules to generate the node evidence requirement set; The dependency chain construction module is used to obtain business records from the source system based on the node evidence requirement set to generate evidence summary nodes, and to construct an evidence dependency chain based on the business support relationship; the evidence dependency chain includes the evidence summary nodes and the location to be obtained; The closed evidence chain generation module is used to locate the evidence gap according to the position to be obtained in the evidence dependency chain, obtain the correction business record to generate the correction evidence summary node, and connect the correction evidence summary node to the evidence dependency chain to generate a closed evidence chain. The blockchain evidence storage module is used to generate a closed-loop evidence package based on the closed evidence chain, and write the evidence package verification summary of the closed-loop evidence package into the blockchain to generate an on-chain verification index.

Images