Evidence fixing method and system based on multi-party consensus based on blockchain

Abstract

This solution belongs to the technical field of evidence fixation, and specifically relates to a method and system for fixing evidence after a multi-party consensus based on blockchain. The method for fixing evidence after a multi-party consensus based on blockchain includes the following steps: S10: The notary node receives a notarization application submitted by a participant, and the notarization application includes the first evidence, the assisting party information and third-party server information associated with the first evidence, and the geographic location information of the assisting party and the participant; S20: The notary node obtains electronic evidence related to the first evidence from the assisting party as the second evidence, and obtains electronic evidence related to the first evidence from the third-party server as assisting evidence, and the notary node selects a verification party from the third-party server and the notary node. This solution solves the problem of high difficulty in the work of notary agencies in the evidence fixation and verification links under the unilateral evidence collection method, while reducing the difficulty of the work of notary agencies and judicial organs, and improving the efficiency of dispute resolution.

Description

Technical Field

[0001] This solution belongs to the field of evidence fixation technology, and specifically involves a method and system for fixing evidence after multi-party consensus based on blockchain. Background Art

[0002] In today's digital age, electronic evidence plays a critical role in legal proceedings, commercial disputes, and intellectual property protection. When parties communicate through third-party software, their personal devices (such as mobile phones and computers) and the third-party platform's servers form a "dual-end recording mechanism"—the personal device stores communication data (such as chat logs and file transfer records) locally, while the third-party platform maintains a cloud backup in accordance with the service agreement, thus forming a complete database of communication content. Should a dispute arise between the parties, these records will serve as key electronic evidence and enter the notarization process. First, the rights holder or a notary public will apply to the personal device holder or the third-party platform for data extraction in accordance with legal procedures. After technical verification confirms that the data has not been tampered with, it will be stored and preserved by a professional notary public, creating a legally binding electronic evidence document. When the rights holder files a lawsuit with the local court (the court where the rights holder is geographically located), the local court, based on the case, will request the electronic evidence document from the professional notary public. The professional notary public will accept the court's request, conduct an investigation, and deliver the electronic evidence document to the local court.

[0003] At present, electronic evidence is mainly obtained from electronic devices through automatic evidence collection devices. For example, Chinese patent CN107688754 A discloses an electronic evidence collection device. This device automatically obtains preservation data by recording the screen or taking screenshots of linked pages and submits it to the evidence collection server. Although it saves manpower and time costs to a certain extent, it has obvious limitations, such as relying solely on device-side operations, which may lead to incomplete data, limited platform background data acquisition, and insufficient timeliness when facing data tampering or deletion. Especially when unilaterally collecting evidence from the right holder, electronic evidence is extremely susceptible to factors such as human tampering, equipment failure or system errors, making it difficult to guarantee the credibility of the evidence and increasing the difficulty of the notary agency's work in the evidence fixation and verification links. In addition, such electronic evidence also requires complex technical verification. First, hash value verification and other technical means must be used to verify the integrity of the data from generation, storage, and extraction, and whether it has been tampered with. If the hash values ​​are inconsistent, it is very likely that the data has been altered. Second, the source of the evidence must be clearly identified, proving that it comes from legal, compliant, and properly functioning equipment or software, and has not been illegally manipulated. At the same time, the extraction process must also follow legal procedures, with detailed records of the time, location, and method of extraction to ensure the legality of the extraction. However, in practice, completing these complex verifications is not only technically demanding but also time-consuming and labor-intensive, further highlighting the limitations of current automated evidence collection methods. Summary of the Invention

[0004] The purpose of this solution is to provide a blockchain-based evidence fixation method and system after multi-party consensus, so as to solve the problem of high difficulty in evidence fixation and verification for notary agencies under the unilateral evidence collection method.

[0005] In order to achieve the above purpose, this solution provides a blockchain-based evidence fixation method after multi-party consensus, including the following steps:

[0006] S10: The notary node receives a notarization application submitted by a participant, wherein the notarization application includes the first evidence, information about the assisting party and the third-party server associated with the first evidence, and geographic location information of the assisting party and the participant.

[0007] S20: The notary node obtains electronic evidence related to the first evidence from the assisting party as second evidence, and obtains electronic evidence related to the first evidence from the third-party server as assisting evidence. The notary node selects a verifier from the third-party server and the notary node. The verifier compares the first evidence with the assisting evidence or the second evidence, and analyzes the comparison results to obtain a notarization result.

[0008] S30: The notarization node stores the first evidence according to the notarization result, obtains the court nodes corresponding to the participating party and the assisting party according to the geographic location information, and sends the first evidence to the court node. After receiving the first evidence, the court node stores the first evidence.

[0009] And, a blockchain-based multi-party consensus evidence fixation system that uses a blockchain-based multi-party consensus evidence fixation method.

[0010] The principles and technical effects of this solution are as follows: First, after receiving the first evidence, this solution obtains the second evidence and supporting evidence from the assisting party associated with the first evidence (i.e., the other party to the first evidence) and a third-party server. This solution then cross-compares the first, second, and supporting evidence through multi-source data, forming a logical closed-loop verification process. This approach effectively identifies unilateral evidence tampering. Furthermore, this solution automatically executes verification rules through smart contracts, reducing manual intervention. Unilateral electronic evidence requires complex technical verification. This solution, based on the analysis of verification results from multiple sources of data, derives notarization results, reducing the complex technical verification process and lowering the workload and difficulty of the notary agency.

[0011] Secondly, this solution automatically links the participating and assisting parties to the court nodes in their respective jurisdictions based on their geographic location information, enabling localized storage and judicial filing of evidence. In the traditional process, notary offices are required to manually submit evidence to the court, which is time-consuming and prone to errors. This solution automatically matches court nodes and synchronizes evidence, achieving "verification and filing at the same time," reducing intermediaries, reducing the workload of courts and notary offices, and improving their efficiency. At the same time, the notary nodes synchronize verified evidence to the court nodes, forming a "notarization-judicial" linkage mechanism to ensure the validity of evidence in legal proceedings. As a judicial institution, the court nodes directly participate in evidence storage, and their endorsement enhances the authority of the evidence. In litigation, the court can directly call upon blockchain-stored evidence data without repeated verification, reducing the cost of producing evidence.

[0012] Furthermore, in this solution, data such as primary evidence, secondary evidence, and supporting evidence is stored dispersed across different nodes (notarization nodes, supporting nodes, third-party servers, and court nodes), rather than centrally stored in a single center. Each node stores only data relevant to its role (e.g., court nodes only store evidence that has passed notarization), and public-private key encryption ensures data access rights. This distributed storage prevents evidence loss due to a single node failure (e.g., a notarization node downtime does not affect data storage at the court node). It also enhances data redundancy through a multi-copy mechanism. Furthermore, if a supporting node fails to provide secondary evidence due to a failure, other nodes can still complete verification using the existing evidence chain, ensuring an uninterrupted process.

[0013] In summary, this solution solves the problem of high difficulty for notarial agencies in the process of evidence fixation and verification under the unilateral evidence collection method, while reducing the difficulty of the work of notarial agencies and judicial organs and improving the efficiency of dispute resolution.

[0014] Furthermore, when the notary node cannot obtain assisting evidence from the third-party server, the notary node will compare the second evidence with the first evidence. If the first evidence is the same as the second evidence, the first evidence will be regarded as authentic as the notarization result; if the second evidence is different from the first evidence, the first evidence will be regarded as questionable as the notarization result.

[0015] When the notary node is unable to obtain supporting evidence from a third-party server, this solution compares the first and second pieces of evidence, shortening verification time and avoiding process interruptions caused by the unavailability of third-party services. At the same time, this degradation mechanism also guarantees the basic operational capabilities of the system, allowing the notary service to continue to operate under non-ideal conditions. If the first and second pieces of evidence are consistent, the evidence is deemed authentic, which not only reduces the cost of evidence collection but also maintains basic credibility. However, if there is a discrepancy between the two, a doubt flag is immediately triggered, effectively preventing fraud risks and providing clear guidance for subsequent manual review.

[0016] Furthermore, the verification party constructs a sensitivity scoring function Assign sensitivity scores to electronic evidence. As shown in the following formula (1):

[0017] (1),

[0018] The verifier uses the keyword matching function to name the entity recognition statistics dynamic weight adjustment factor. The matching formula is shown in the following formula (2):

[0019] (2),

[0020] When satisfied When the privacy protection mode is triggered, the threshold Calculated by the following formula (3):

[0021] (3),

[0022] in, is the mean sensitivity of historical data, is the standard deviation, is the confidence coefficient;

[0023] The verifier uses zero-knowledge proof technology to prove the consistency of the second evidence or auxiliary evidence with the first evidence.

[0024] Furthermore, when the verifier uses zero-knowledge proof technology to prove the consistency of the second evidence or the auxiliary evidence with the first evidence, the following steps are included:

[0025] A10: Define the validation relationship , As shown in the following formula (4):

[0026] (4),

[0027] in As the first evidence, as secondary evidence or supporting evidence;

[0028] A20: The verifier uses zk-STARKs to construct the proof , As shown in the following formula (5):

[0029] (5),

[0030] The commitment function satisfies ;

[0031] A30: Verification and If they are consistent, the verification party executes , if and only if When confirming and The content is consistent; is a safety parameter, is an ignorable function.

[0032] This solution, through its dynamic sensitivity scoring system, not only accurately identifies explicit sensitive information such as ID numbers and medical records, but also captures contextual privacy through named entity recognition and adaptive weight adjustment, improving the accuracy of identifying private content. Furthermore, the zk-STARKs-based verification protocol ensures the non-interactive nature of the verification process while guaranteeing zero leakage of original evidence through cryptographic commitment functions. This reduces evidence storage overhead while meeting stringent privacy requirements such as HIPAA and GDPR. This solution implements intelligent risk control through a dynamic threshold mechanism: as the entropy of the historical data distribution increases, the confidence coefficient automatically increases, making the solution more responsive to new sensitive patterns while maintaining a low false positive rate. In particular, in scenarios such as cross-institutional medical notarization, the use of quantum-safe hash commitment technology not only protects against future computational attacks but also enables the rapid completion of large numbers of concurrent verifications in a short period of time, ultimately forming a complete closed loop of "accurate identification, efficient verification, and compliant evidence storage."

[0033] Furthermore, when the notary node sends the first evidence to the court node, an alliance is established between the local notary node and each court node based on blockchain technology, and each node in the alliance follows the consensus mechanism; a dedicated sub-chain is established in the alliance chain for the first evidence, and the sub-chain adopts sharding storage technology to perform hash operation on the first evidence to generate a unique hash value, trigger the chain operation through the smart contract, and store the hash value and metadata of the first evidence in the sub-chain block; after each court node monitors the chain operation of the sub-chain through the consensus algorithm, it automatically synchronizes and verifies the hash value, encrypts the chain content and the corresponding hash value and stores it in the blockchain database of the local node, and updates the evidence index table of the local node at the same time, and ensures the integrity verification of the stored data through the Merkle-Patricia tree structure.

[0034] When the notary node transmits the first evidence to each court node, it builds a consortium chain network based on blockchain technology and establishes alliances with each court node. Each node follows a consensus mechanism to achieve trusted collaboration, avoiding the trust risks of a single node dominating. The consortium chain's permission control mechanism ensures that only judicial nodes participate, ensuring the secure flow of evidence. A dedicated subchain is established within the consortium chain for the first evidence, using sharded storage technology to reduce data pressure on the main chain. A smart contract triggers a hash operation to generate a unique hash value, which is then uploaded to the chain along with metadata such as evidence type, generation time, and geolocation. This not only reduces bandwidth consumption associated with transmitting complete evidence files, but also ensures evidence integrity through the hash value's immutability—if the evidence content is modified, the hash value will completely change, making tampering quickly detectable. Upon detecting the subchain upload operation through a consensus algorithm, each court node automatically synchronizes and verifies the hash value, encrypting the uploaded content and hash value and storing it in a local blockchain database. The evidence index table is also updated, and integrity verification using a Merkle-Patricia tree structure ensures consistency between the locally stored data and the on-chain data. During this process, the blockchain timestamp accurately records the time of evidence storage to meet the judicial timeliness requirements. Distributed storage allows the hash value of evidence to be dispersed across nodes, and the failure of a single node does not affect the integrity of the evidence. The layered design of the sub-chain and the main chain enhances the risk resistance of this solution, and ultimately achieves efficient and synchronous verification of evidence across regions, enhanced legal effectiveness, and data security. It not only optimizes the efficiency of the judicial process, but also ensures the credibility and non-tamperability of evidence in the judicial chain through technical mechanisms.

[0035] Furthermore, when a court node obtains electronic evidence, it first queries the electronic evidence locally as initial evidence, then obtains the court node corresponding to the geographic location information associated with the initial evidence as an assisting court, obtains electronic evidence related to the initial evidence from the assisting court as verification evidence, compares the verification evidence with the initial evidence, and if the results are consistent, outputs the initial evidence as final evidence. If the results are inconsistent, obtains electronic evidence related to the initial evidence from the notary node as re-examination evidence, compares the re-examination evidence, verification evidence and initial evidence, and selects the final evidence from the re-examination evidence, verification evidence or initial evidence based on the comparison results.

[0036] Furthermore, if the re-examination evidence, verification evidence or initial evidence are all different, the re-examination evidence, verification evidence or initial evidence will be divided into equal length sections, for Calculate the cross-similarity matrix of the three-party evidence, determine the party with complete evidence content based on the calculated similarity, and then The subsections are combined into a complete piece of evidence as the final evidence output.

[0037] First, the three-level verification process (court node → assisting court → notarization node) established by this solution, namely "initial evidence - verification evidence - re-examination evidence," not only enhances the credibility of evidence through multi-party cross-validation but also provides an authoritative data source for subsequent block repair. Furthermore, the block similarity analysis mechanism introduced in this solution not only locates byte-level differences when the evidence from the three parties is completely inconsistent, but also intelligently selects the optimal evidence block through dynamic weighting, thereby speeding up evidence verification in complex scenarios. Of particular note is that when basic inconsistencies are detected, the solution's fault-tolerant reconstruction capability automatically repairs evidence. This shortens the processing cycle in some complex scenarios (such as cross-border contract disputes) while reducing storage costs.

[0038] Furthermore, after the notary node divides the electronic evidence, it calculates the first The controversy coefficient of each section , The calculation formula is shown in the following formula (11):

[0039] (11),

[0040] when When the first The subsections are marked as disputed blocks. Set a preset dispute threshold; allocate verification computing power to disputed blocks , As shown in the following formula (12):

[0041] (12),

[0042] in, is the set of all disputed blocks in the current window, As the benchmark computing resource; a hybrid verification model is used to perform deep verification on the disputed blocks. The hybrid verification model is shown in the following formula (13):

[0043] (13),

[0044] Among them, cryptographic similarity Calculated based on the Merkle-Patricia tree, semantic similarity Calculated using the BERT model, the weight coefficient is: ;

[0045] When m consecutive blocks satisfy: Immediately release the verification computing power allocated to this batch.

[0046] This solution utilizes a quantitative dispute coefficient assessment model that not only accurately identifies highly controversial blocks but also intelligently allocates computing power through flexible resource allocation, improving resource utilization during block testing. Furthermore, the hybrid verification model retains the cryptographic rigor of Merkle tree validation while incorporating BERT semantic analysis to detect traces of content tampering, thereby reducing the misjudgment rate for complex evidence.

[0047] Furthermore, the notary node compares the final evidence with the electronic evidence stored by the court node to obtain the completeness of the electronic evidence, and assigns a confidence score to the court node based on the completeness. The court node selects the node to assist the court based on the confidence score.

[0048] This solution, based on a complete quantitative model, not only objectively assesses evidence quality but also establishes an adaptive reputation score for court nodes through an exponential smoothing algorithm, improving the identification of malicious nodes. Furthermore, a topology optimization algorithm is employed to assist courts in selecting and prioritizing high-reputation nodes, shortening court collaboration latency and improving the efficiency of court nodes in comparing electronic evidence. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] Figure 1 This is a flowchart of a method for fixing evidence after multi-party consensus based on blockchain in an embodiment of the present invention. DETAILED DESCRIPTION

[0050] The following will clearly and completely describe the concept and technical effects of the present invention in conjunction with the embodiments to fully understand the purpose, features and effects of the present invention. Obviously, the embodiments described are only part of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, other embodiments obtained by those skilled in the art without creative work are all within the scope of protection of the present invention:

[0051] like Figure 1 As shown in FIG, the evidence fixing method after multi-party consensus based on blockchain includes the following steps:

[0052] S10: The notary node receives a notarization application submitted by a participant, wherein the notarization application includes the first evidence, information about the assisting party and the third-party server associated with the first evidence, and geographic location information of the assisting party and the participant.

[0053] S20: The notary node obtains electronic evidence related to the first evidence from the assisting party as second evidence, and obtains electronic evidence related to the first evidence from the third-party server as assisting evidence. The notary node selects a verifier from the third-party server and the notary node. The verifier compares the first evidence with the assisting evidence or the second evidence, and analyzes the comparison results to obtain a notarization result.

[0054] S30: The notarization node stores the first evidence according to the notarization result, obtains the court nodes corresponding to the participating party and the assisting party according to the geographic location information, and sends the first evidence to the court node. After receiving the first evidence, the court node stores the first evidence.

[0055] Among them, the verification party constructs a sensitivity scoring function Assign sensitivity scores to electronic evidence. As shown in the following formula (1):

[0056] (1),

[0057] The verifier uses the keyword matching function to name the entity recognition statistics dynamic weight adjustment factor. The matching formula is shown in the following formula (2):

[0058] (2),

[0059] When satisfied When the privacy protection mode is triggered, the threshold Calculated by the following formula (3):

[0060] (3),

[0061] in, is the mean sensitivity of historical data, is the standard deviation, is the confidence coefficient; the verifier uses zero-knowledge proof technology to prove the consistency of the second evidence or auxiliary evidence with the first evidence.

[0062] Specifically, when the verifier uses zero-knowledge proof technology to prove the consistency of the second evidence or the auxiliary evidence with the first evidence, the following steps are included:

[0063] A10: Define the validation relationship , As shown in the following formula (4):

[0064] (4),

[0065] in As the first evidence, as secondary evidence or supporting evidence;

[0066] A20: The verifier uses zk-STARKs to construct the proof , As shown in the following formula (5):

[0067] (5),

[0068] The commitment function satisfies ;

[0069] A30: Verification and If they are consistent, the verification party executes , if and only if When confirming and The content is consistent; is a safety parameter, is an ignorable function.

[0070] When the notary node transmits the first evidence to each court node, it builds a consortium chain network based on blockchain technology and establishes alliances with each court node. Each node follows a consensus mechanism to achieve trusted collaboration, avoiding the trust risks of a single node dominating. The consortium chain's permission control mechanism ensures that only judicial nodes participate, ensuring the secure flow of evidence. A dedicated subchain is established within the consortium chain for the first evidence, using sharded storage technology to reduce data pressure on the main chain. A smart contract triggers a hash operation to generate a unique hash value, which is then uploaded to the chain along with metadata such as evidence type, generation time, and geolocation. This reduces bandwidth consumption associated with transmitting complete evidence files and ensures evidence integrity through the hash value's immutability—if the evidence content is modified, the hash value will completely change, making tampering quickly detectable. Upon detecting the subchain upload operation through a consensus algorithm, each court node automatically synchronizes and verifies the hash value, encrypting the uploaded content and hash value and storing it in a local blockchain database. The evidence index table is also updated, and integrity verification using a Merkle-Patricia tree structure ensures consistency between the locally stored data and the on-chain data. During this process, the blockchain timestamp accurately records the time of evidence storage to meet the judicial timeliness requirements. Distributed storage allows the hash value of evidence to be dispersed across nodes, and the failure of a single node does not affect the integrity of the evidence. The layered design of the sub-chain and the main chain enhances the risk resistance of this solution, and ultimately achieves efficient and synchronous verification of evidence across regions, enhanced legal effectiveness, and data security. It not only optimizes the efficiency of the judicial process, but also ensures the credibility and non-tamperability of evidence in the judicial chain through technical mechanisms.

[0071] Among them, when the court node obtains electronic evidence, it first queries the electronic evidence locally as the initial evidence, and then obtains the court node corresponding to the geographic location information associated with the initial evidence as the assisting court, obtains electronic evidence related to the initial evidence from the assisting court as verification evidence, compares the verification evidence with the initial evidence, and if the results are consistent, the initial evidence is output as the final evidence. If the results are inconsistent, the electronic evidence related to the initial evidence is obtained from the notary node as re-examination evidence, compares the re-examination evidence, verification evidence and initial evidence, and selects the final evidence from the re-examination evidence, verification evidence or initial evidence according to the comparison results.

[0072] Specifically, if the re-examination evidence, verification evidence or initial evidence are all different, the re-examination evidence, verification evidence or initial evidence shall be divided into equal length sections, for Calculate the cross-similarity matrix of the three-party evidence, determine the party with complete evidence content based on the calculated similarity, and then The subsections are combined into a complete piece of evidence as the final evidence output.

[0073] More specifically, when reviewing the evidence , verify evidence With initial evidence If all are inconsistent, follow the steps below to generate the final evidence :

[0074] B10: The notary node divides each piece of evidence into equal length sections, block length Satisfies the following formula (6):

[0075] (6),

[0076] in is the minimum block threshold (default 4KB), Indicates the length of the evidence in bytes.

[0077] B20: Notary Node Sections ( ), calculate the cross-similarity matrix of the three-party evidence , As shown in the following formula (7):

[0078] (7),

[0079] The similarity function Defined as ; is the locality sensitive hashing similarity, is the information entropy function, is the smoothing factor.

[0080] B30: Notary Node Selection Final version of the section Satisfies the following formula (8):

[0081] (8),

[0082] Weight The credibility of the evidence source is distributed as shown in the following formula (9):

[0083] (9),

[0084] B40: Final Evidence The consistency check needs to be satisfied, as shown in the following formula (10):

[0085] (10),

[0086] in is the similarity threshold, is the indicator function.

[0087] More specifically, the block processing adopts a dynamic adjustment strategy. The sliding window mechanism is enabled when: After the evidence is reorganized, the Merkle hash tree consistency needs to be verified.

[0088] Specifically, after the notary node divides the electronic evidence, it calculates the first The controversy coefficient of each section , The calculation formula is shown in the following formula (11):

[0089] (11),

[0090] when When the first The subsections are marked as disputed blocks. The default dispute threshold is 0.7; verification computing power is allocated to disputed blocks. , As shown in the following formula (12):

[0091] (12),

[0092] in, is the set of all disputed blocks in the current window, As the benchmark computing resource; a hybrid verification model is used to perform deep verification on the disputed blocks. The hybrid verification model is shown in the following formula (13):

[0093] (13),

[0094] Among them, cryptographic similarity Calculated based on the Merkle-Patricia tree, The calculation formula is shown in the following formula (14):

[0095] (14),

[0096] Semantic similarity Calculated using the BERT model, The calculation formula is shown in the following formula (15):

[0097] (15),

[0098] Weight coefficient ;

[0099] When m consecutive blocks satisfy: Immediately release the verification computing power allocated to this batch.

[0100] The resource allocation formula ensures (Total system resources).

[0101] Among them, the notary node compares the final evidence with the electronic evidence stored by the court node to obtain the completeness of the electronic evidence, and assigns a confidence score to the court node based on the completeness. The court node selects and assists the court based on the confidence score.

[0102] Specifically, the court node compares the final evidence Storing evidence with court nodes , calculate the completeness of evidence , the calculation formula is shown in the following formula (16):

[0103] (16),

[0104] in, Match the number of bytes for evidence, is the timestamp difference, The maximum allowed delay (default is 24 hours).

[0105] Specifically, the court node Rating Updated by exponential smoothing method, The calculation formula is shown in the following formula (17):

[0106] (17),

[0107] in , the scores are uploaded to the chain in real time and affect the subsequent selection of assisting courts.

[0108] Specifically, when choosing to assist the court, give priority to: ;in is the reputation weight, is the network delay between nodes.

[0109] This embodiment also includes a blockchain-based multi-party consensus evidence fixation system that uses a blockchain-based multi-party consensus evidence fixation method.

[0110] During a specific implementation, a technology company and a partner enterprise had a dispute over the authenticity of an electronic contract. The technology company (the party involved) claimed that the payment terms in the contract had been tampered with, while the partner enterprise insisted that the contract had not been altered. To resolve this dispute, the two parties decided to adopt a blockchain-based multi-party consensus evidence fixation system. Through the coordinated operation of notary nodes, assisting nodes (the partner enterprise), third-party servers, and court nodes, the electronic contract can be reliably fixed and verified.

[0111] The technology company (participating party) submits a notarization application to the notarization node. The application includes the electronic contract (first evidence), information about the cooperative enterprise (assisting party), information about the third-party cloud storage server, and the geographic location information of both parties (for example, the technology company is located in City A and the cooperative enterprise is located in City B).

[0112] After receiving the application, the notary node sends a request to the partner (assisting party) to obtain a stored copy of the same electronic contract as secondary evidence. Simultaneously, the notary node accesses a third-party cloud storage server to retrieve a historical version of the electronic contract as supporting evidence.

[0113] The notary node selects a verifier from a third-party server or its own node to compare the first, second, and supporting evidence. The verifier first compares the first and supporting evidence and discovers a discrepancy in their hash values, indicating possible tampering with the electronic contract. Unable to obtain valid supporting evidence from the third-party server, the verifier then compares the first and second evidence. A page-by-page comparison reveals significant discrepancies in the payment terms of the contract (the contract provided by the technology company states "payment period is 30 working days," while the contract provided by the partner company states "payment period is 60 working days"). The verifier analyzes the electronic contract using a sensitivity scoring function and identifies that the payment terms involve commercially sensitive information. Because the sensitivity score exceeds a preset threshold, the system automatically triggers privacy protection mode and verifies the consistency of the evidence using zero-knowledge proof technology. This ensures that substantive differences between the contract versions provided by both parties are proven without revealing the specific content of the contract.

[0114] Based on the comparison results, the notary node marks the electronic contract as "doubtful" and stores the first piece of evidence. Subsequently, the system automatically associates the two parties' geographic locations with the corresponding court nodes: the technology company with the Intermediate People's Court of City A, and the cooperative enterprise with the Basic People's Court of City B. The notary node synchronizes the questionable electronic contract with these two court nodes for storage, ensuring localized filing of evidence.

[0115] The court node first retrieves the electronic contract from local storage as initial evidence. Based on the geographic location associated with the initial evidence, it then applies to the grassroots People's Court of City B (the assisting court) for verification evidence. The grassroots People's Court of City B returns a copy of the electronic contract it has stored (which is consistent with the secondary evidence provided by the partner enterprise).

[0116] The trial court compared the verification evidence with the initial evidence and discovered inconsistencies. It then requested re-verification evidence from the notary node. Due to discrepancies among the initial, verification, and re-verification evidence, the notary node segmented the three pieces of evidence into multiple sections of equal length (e.g., by page number) and calculated a cross-similarity matrix for each section. Analysis of the similarity of each section revealed significant differences between the payment terms section in the re-verification evidence (notary node evidence) and the initial evidence (trial court evidence), while showing lower similarity with the corresponding section in the verification evidence (assisting court evidence). The notary node marked these sections with unusually high similarities as disputed blocks and allocated additional verification computing power for in-depth verification. Using a hybrid verification model (combining Merkle-Patricia tree cryptography and BERT semantic analysis), the notary node detected signs of tampering with the payment terms, confirming that the contract version provided by the partner company was potentially forged.

[0117] The notarization node regularly compares the final evidence with the evidence stored in the court node, calculates the completeness of each court node (for example, the evidence completeness of the node of the Intermediate People's Court of City A is 98%, and the evidence completeness of the node of the Basic People's Court of City B is 75%), and assigns a confidence score to the court node based on the completeness. In subsequent cases, the presiding court will give priority to selecting court nodes with high confidence scores (such as the Intermediate People's Court of City A) as assisting courts to ensure the accuracy and efficiency of evidence verification.

[0118] The above is only an embodiment of the present invention, and the common knowledge such as the specific structure and characteristics of the scheme is not described in detail here. It should be pointed out that for those skilled in the art, without departing from the structure of the present invention, several variations and improvements can be made, which should also be regarded as the scope of protection of the present invention, and these will not affect the effect of the implementation of the present invention and the practicality of the patent. The scope of protection required by this application shall be based on the content of its claims, and the specific implementation methods and other records in the specification can be used to interpret the content of the claims.

Claims

1. The evidence fixing method after multi-party consensus based on blockchain is characterized by: The following steps are involved: S10: The notary node receives a notarization application submitted by a participant, wherein the notarization application includes the first evidence, information about the assisting party and the third-party server associated with the first evidence, and geographic location information of the assisting party and the participant. S20: The notary node obtains electronic evidence related to the first evidence from the assisting party as second evidence, and obtains electronic evidence related to the first evidence from the third-party server as assisting evidence. The notary node selects a verifier from the third-party server and the notary node. The verifier compares the first evidence with the assisting evidence or the second evidence, and analyzes the comparison results to obtain a notarization result. S30: The notary node stores the first evidence based on the notarization result, obtains the court nodes corresponding to the participating party and the assisting party based on the geographic location information, and sends the first evidence to the court node. The court node stores the first evidence after receiving it. When a court node obtains electronic evidence, it first queries the local electronic evidence as initial evidence, then obtains the court node corresponding to the geographic location information associated with the initial evidence as an assisting court, obtains electronic evidence related to the initial evidence from the assisting court as verification evidence, compares the verification evidence with the initial evidence, and outputs the initial evidence as final evidence if the results are consistent. If the results are inconsistent, it obtains electronic evidence related to the initial evidence from the notary node as re-examination evidence, compares the re-examination evidence, verification evidence, and initial evidence, and selects the final evidence from the re-examination evidence, verification evidence, or initial evidence based on the comparison results. If the re-examination evidence, verification evidence or initial evidence are all different, the re-examination evidence, verification evidence or initial evidence shall be divided into equal length sections, for Calculate the cross-similarity matrix of the three-party evidence, determine the party with complete evidence content based on the calculated similarity, and then The subsections are combined into a complete evidence as the final evidence output; After the notary node divides the electronic evidence, it calculates the first The controversy coefficient of each section , The calculation formula is shown in the following formula (11): （11）， when When the first The subsections are marked as disputed blocks. Set a preset dispute threshold; allocate verification computing power to disputed blocks , As shown in the following formula (12): （12）， in, is the set of all disputed blocks in the current window, As the benchmark computing resource; a hybrid verification model is used to perform deep verification on the disputed blocks. The hybrid verification model is shown in the following formula (13): （13）， Among them, cryptographic similarity Calculated based on the Merkle-Patricia tree, semantic similarity Calculated using the BERT model, the weight coefficient is: ; When m consecutive blocks satisfy: Immediately release the verification computing power allocated to this batch.

2. The blockchain-based multi-party consensus evidence fixation method according to claim 1, characterized in that: When the notary node cannot obtain assisting evidence from the third-party server, the notary node will compare the second evidence with the first evidence. If the first evidence is the same as the second evidence, the first evidence will be regarded as authentic as the notarization result; if the second evidence is different from the first evidence, the first evidence will be regarded as questionable as the notarization result.

3. The blockchain-based multi-party consensus evidence fixation method according to claim 2 is characterized by: The validation party constructs a sensitivity scoring function Assign sensitivity scores to electronic evidence. As shown in the following formula (1): （1）， The verifier uses the keyword matching function to identify the statistical dynamic weight adjustment factor of the named entity. The matching formula is shown in the following formula (2): （2）， When satisfied When the privacy protection mode is triggered, the threshold Calculated by the following formula (3): （3）， in, is the mean sensitivity of historical data, is the standard deviation, is the confidence coefficient; The verifier uses zero-knowledge proof technology to prove the consistency of the second evidence or auxiliary evidence with the first evidence.

4. The blockchain-based evidence fixation method after multi-party consensus according to claim 3 is characterized by: When the verifier uses zero-knowledge proof technology to prove the consistency of the second evidence or auxiliary evidence with the first evidence, the following steps are included: A10: Define the validation relationship , As shown in the following formula (4): （4）， in As the first evidence, as secondary evidence or supporting evidence; A20: The verifier uses zk-STARKs to construct the proof , As shown in the following formula (5): （5）， The commitment function satisfies ; A30: Verification and If they are consistent, the verification party executes , if and only if When confirming and The content is consistent; is a safety parameter, is an ignorable function.

5. The blockchain-based multi-party consensus evidence fixation method according to claim 4 is characterized by: When the notary node sends the first evidence to the court node, it establishes an alliance with the local notary node and each court node based on blockchain technology. Each node in the alliance follows a consensus mechanism. A dedicated sub-chain is established within the alliance chain for the first evidence. The sub-chain uses sharding storage technology to perform a hash operation on the first evidence to generate a unique hash value. The on-chain operation is triggered by a smart contract, and the hash value and metadata of the first evidence are stored in the sub-chain block. After each court node monitors the sub-chain's on-chain operation through the consensus algorithm, it automatically synchronizes and verifies the hash value, encrypts the on-chain content and the corresponding hash value and stores it in the blockchain database of the local node. At the same time, it updates the evidence index table of the local node and ensures the integrity verification of the stored data through the Merkle-Patricia tree structure.

6. The blockchain-based multi-party consensus evidence fixation method according to claim 5 is characterized by: The notary node compares the final evidence with the electronic evidence stored by the court node to obtain the completeness of the electronic evidence, and assigns a confidence score to the court node based on the completeness. The court node selects the node to assist the court based on the confidence score.

7. The blockchain-based evidence fixing system after multi-party consensus is characterized by: The method for fixing evidence after multi-party consensus based on blockchain as described in any one of claims 1-6 is used.

Images