Electronic contract signing method based on blockchain storage

Abstract

The application discloses an electronic contract signing method based on blockchain storage, and particularly relates to the technical field of electronic evidence preservation and smart contract; original data of an electronic contract is acquired and a hash digest is generated; a plurality of candidate blockchain networks are set as storage target chains; the transaction density index and network propagation lag of each chain are collected in real time; the above parameters are input into a risk scoring model to calculate a comprehensive risk score; a strategic broadcast operation is performed according to the scoring result; the transaction confirmation state is listened to, and the first blockchain reaching a set number of confirmations is selected as the main storage chain; and when storage fails, off-chain supplementary storage or re-broadcasting is triggered; the application can dynamically perceive the chain state, adaptively select the best storage path, effectively improve the on-chain success rate of the electronic contract and its legal effect, has strong disaster recovery capability and cross-chain applicability, and is suitable for high-evidence-reliability-required scenes such as judicature, finance and government affairs.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of electronic evidence preservation and smart contract, and particularly relates to an electronic contract signing method based on blockchain storage. BACKGROUND

[0002] Blockchain storage refers to the encryption storage and time stamping of key information of data, files or events by using blockchain technology, so as to realize the tamper-proof and traceable electronic evidence preservation mode. This mode ensures that the data cannot be forged or tampered after being chained, and can be used in intellectual property protection, contract performance, judicial evidence collection and other scenarios, thereby improving the credibility and legal effect of electronic evidence.

[0003] When using a public chain (such as Ethereum main network or Polygon) based on PoW or PoS for electronic contract storage, the transaction may be packaged into an “orphan block” instead of the final main chain; if a chain reorganization (fork) occurs subsequently, the original block is rolled back, and the transaction is also invalidated, resulting in no record of the txHash on the chain. Although this fork mechanism is part of the normal consensus process of the blockchain, it will cause the “transaction uncertainty” problem for the storage system, and it must wait for multiple block confirmations (such as 12 confirmations) to ensure the finality of the transaction, otherwise the user may mistakenly think that the data is lost, affecting trust and experience. SUMMARY

[0004] The purpose of the present application is to provide an electronic contract signing method based on blockchain storage, to solve the problems in the background art.

[0005] In order to achieve the above-mentioned purpose, the present application provides the following technical solution: an electronic contract signing method based on blockchain storage, comprising:

[0006] Obtaining the original data of the electronic contract to be signed, and performing a hash operation thereon to generate a contract digest hash value;

[0007] Setting a plurality of candidate blockchain networks as storage target chains, including public chains based on proof of work or proof of stake mechanism;

[0008] For each candidate blockchain network, real-time collection of transaction density index and network propagation lag;

[0009] Inputting the transaction density index and network propagation lag into a risk scoring model to calculate the comprehensive risk score value of each candidate blockchain:

[0010] According to the comprehensive risk score value, a strategic broadcast operation is performed on each candidate blockchain, including: when the risk score is lower than a first threshold value, immediately submitting the contract digest hash value to the corresponding blockchain; when the risk score is between the first threshold value and a second threshold value, delaying the broadcast or broadcasting to multiple chains at the same time; when the risk score is higher than the second threshold value, postponing the submission and triggering a backup mechanism;

[0011] The transaction confirmation state of each target blockchain is listened to, and the first blockchain reaching a set confirmation number is selected as the main storage chain, and the transaction hash, block height and confirmation time are recorded;

[0012] The storage result and chain state score record are archived, and in the case of storage failure, a chain-offline supplementary storage or re-broadcast is triggered.

[0013] Preferably, the hash operation on the original data of the electronic contract includes:

[0014] The uploaded electronic contract file is preprocessed, including character encoding unification, dynamic field cleaning and content structuring operation;

[0015] The processed contract file is read as a standard byte stream;

[0016] The byte stream is encrypted using a secure hash algorithm to generate a fixed-length hash digest;

[0017] The hash digest is packaged into a metadata structure together with the hash algorithm identifier, processing rule and version number.

[0018] Preferably, the real-time collection of the transaction density index includes:

[0019] The size of the sliding window is set to the latest N blocks, and the transaction quantity of the i-th block is obtained ; the mean value is calculated using the exponentially weighted moving average method , the dynamic standard deviation is calculated , that is, the transaction density index is calculated.

[0020] Preferably, the calculation method of the network propagation lag NPLS includes:

[0021] The blockchain network is modeled as a directed graph G=(V,E), where the nodes V represent the main nodes of the whole network, and the edges E represent the connection paths;

[0022] The starting time of the to-be-submitted transaction record is recorded, and by listening to the P2P network Gossip protocol or receiving confirmation events, the receiving time of each receiving node is recorded; the propagation delay of each node is calculated, and the expression is: ; the weight is assigned , the network propagation lag is calculated, and the expression is: ; n is the total number of nodes.

[0023] Preferably, the transaction density index and the network propagation lag are converted into a comprehensive feature vector, the comprehensive feature vector is taken as an input of a machine learning model, the machine learning model takes a risk score value label of each candidate chain as a prediction target to minimize the sum of prediction errors of risk score value labels of all candidate chains as a training target, the machine learning model is trained until the sum of prediction errors converges, and the risk score value R of each candidate chain is determined according to a model output result, wherein the machine learning model is a polynomial regression model.

[0024] Preferably, the step of monitoring transaction confirmation states and selecting a main storage evidence chain comprises:

[0025] A monitoring channel is configured for each candidate chain, and a transaction state is monitored in real time through a block chain node interface;

[0026] A confirmation block threshold is set, and when the transactions on a certain chain reach a preset number of confirmation blocks, a confirmation timestamp is recorded;

[0027] The first chain that meets the confirmation condition is marked as the main storage evidence chain;

[0028] The transaction hash, block height, transaction confirmation time, and main chain identifier are recorded synchronously as storage indexes.

[0029] Preferably, the step of triggering off-chain supplementary storage or rebroadcasting in the case of storage failure comprises:

[0030] It is determined that the transaction is not confirmed on the chain within a specified time window or is rolled back by chain reorganization after being packaged;

[0031] A timestamp service is called to generate an off-chain digital signature certificate, and the certificate contains a contract digest hash, a failed chain identifier, and a timestamp;

[0032] The certificate is digitally signed using a platform private key, and the certificate is submitted to a trusted off-chain storage platform or database;

[0033] According to the current risk score, a low-risk candidate chain is selected again, and a storage transaction is constructed and rebroadcasted.

[0034] In the above technical solution, the present application provides technical effects and advantages:

[0035] 1、The application introduces multi-chain dynamic selection and intelligent broadcast mechanism, combines transaction density index and network propagation lag two key indicators, constructs risk scoring model, can judge the best storage path according to the chain state in real time.The mechanism effectively avoids the problems such as transaction rollback, storage failure caused by blockchain bifurcation, transaction congestion or network instability, significantly improves the success rate of electronic contract storage and the final consistency of data.

[0036] 2、The application also provides a disaster recovery mechanism for off-chain supplementary storage and rebroadcast, ensures that even if the on-chain storage fails, a timestamp signature evidence with legal effect can still be formed, and the availability and credibility of electronic contracts in rigorous scenarios such as judicial and arbitration are ensured.The overall scheme has high security, flexibility and cross-chain adaptability, and is suitable for electronic contract signing and storage needs in a multi-source heterogeneous blockchain environment. BRIEF DESCRIPTION OF DRAWINGS

[0037] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings needed in the embodiments will be briefly introduced below, and obviously, the drawings described below are only some embodiments described in the present application, and other drawings can also be obtained by those skilled in the art based on these drawings.

[0038] Figure 1 The method flowchart of the present application. DETAILED DESCRIPTION

[0039] In order to make the purpose, technical scheme and advantages of the embodiments of the present application more clear, the technical scheme in the embodiments of the present application will be described clearly and completely below in conjunction with the drawings in the embodiments of the present application, obviously, the described embodiments are part of the embodiments of the present application, not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the present application.

[0040] Embodiment 1, please refer to Figure 1 The electronic contract signing method based on blockchain storage described in the present embodiment comprises:

[0041] Obtain the original data of the electronic contract to be signed, and perform hash operation on it to generate a contract digest hash value;

[0042] Set a plurality of candidate blockchain networks as storage target chains, including public chains based on proof of work or proof of stake mechanism;

[0043] For each candidate blockchain network, real-time acquisition of transaction density index and network propagation lag;

[0044] The transaction density index and network propagation lag are input into a risk scoring model to calculate a comprehensive risk score value for each candidate blockchain:

[0045] According to the comprehensive risk score value, a strategic broadcast operation is performed on each candidate blockchain, including: when the risk score is below a first threshold value, immediately submitting the contract summary hash value to the corresponding blockchain; when the risk score is between the first threshold value and a second threshold value, delaying the broadcast or broadcasting to multiple chains simultaneously; when the risk score is higher than the second threshold value, postponing the submission and triggering a backup mechanism.

[0046] The transaction confirmation state of each target blockchain is listened to, and the first blockchain that reaches a set confirmation number is selected as the main storage chain, and the transaction hash, block height and confirmation time are recorded.

[0047] The storage result and chain state score record are archived, and in the case of storage failure, a chain storage supplement or re-broadcast is triggered.

[0048] In the electronic contract blockchain storage method proposed in the present application, the first step is to standardize the format of the electronic contract data to be signed and perform a cryptographic hash operation to generate a contract summary value with uniqueness and irreversibility, which is the core identifier for subsequent blockchain storage and transaction identification.

[0049] Specifically, the user uploads the contract document to be signed through the electronic contract management platform, which can be a structured contract text in PDF, DOCX, HTML or JSON format. The system first performs content specification processing on the original file of the electronic contract to ensure consistency of the document content in different terminal and system environments. For example, embed fonts uniformly in PDF files, clear dynamic content and interactive fields, and parse according to the preset character encoding method. The purpose of this processing is to generate consistent hash values for the same content on different devices, avoiding conflicts in subsequent storage due to format differences.

[0050] After preprocessing is completed, the system performs a hash operation on the contract document content. The hash operation uses a secure cryptographic hash algorithm, such as SHA-256 (Secure Hash Algorithm 256 bits). This algorithm has collision resistance and one-wayness, which can ensure that even if the contract document changes only one character, the generated hash value will be completely different, thereby achieving high-strength content unique identification.

[0051] In a specific implementation, the system reads the contract content as a binary byte stream, performs an encryption hash operation on the byte stream, and generates a fixed-length hash digest. For example, when using the SHA-256 algorithm, a contract data of any length will output a hash string of 256 bits (binary) or 64 bits (hexadecimal representation). For example, if the contract content is "Contract No. HT20250729, Party A: A Company, Party B: B Company", the calculated hash value may be: 5e884898da28047151d0e56f8dc6292773603d0d6aabbdd7eb62e63c06bce876; this hash value is the unique content digest identifier of the contract in this signing and notarization process.

[0052] The hash value does not contain the contract content itself and has good privacy protection properties. At the same time, as the digest carrier of subsequent on-chain transaction data, it effectively reduces the blockchain storage overhead. In addition, since the hash algorithm itself is an irreversible process, even if an attacker intercepts the hash value, the original text of the contract cannot be restored, further ensuring the confidentiality of the contract content.

[0053] To ensure the stability and judicial verifiability of the hash value, the system also records the calculation algorithm, input format specification, and version number of the digest value. For example, for SHA-256 hash calculation, the following parameters are recorded:

[0054] Hash algorithm: SHA-256;

[0055] Input character encoding: UTF-8;

[0056] File preprocessing standard: contract content structured cleaning v1.2;

[0057] This metadata can be notarized together with the hash value to provide verifiable evidence for subsequent compliance audits by courts or third-party institutions.

[0058] In summary, this step not only generates a unique identifier for the contract data in the on-chain notarization process, but also ensures the stability, privacy, and legal basis of the electronic contract content through standardized processing and encryption mechanisms. It is the core starting point of the entire blockchain notarization method.

[0059] To enhance the robustness and reliability of the electronic contract notarization system in different network environments, node topologies, and chain stability conditions, the present invention proposes a multi-chain redundancy mechanism, which pre-sets multiple candidate blockchain networks as potential notarization target chains. This mechanism breaks through the technical limitations of traditional single main chain notarization, enabling the system to dynamically select the optimal chain for broadcasting and recording based on chain status, thereby significantly reducing the probability of notarization failure due to chain bifurcation, network congestion, chain collapse, and other abnormal situations.

[0060] The candidate blockchain network includes but is not limited to the following types:

[0061] Blockchain based on Proof of Work (PoW) mechanism, such as Ethereum mainnet (version before merge), Bitcoin mainnet (for timestamp verification), Conflux, etc. Such public chains compete for packaging rights through computing resources, have strong decentralization and attack resistance, but have the problems of unpredictable block time, long transaction confirmation time, and are subject to high network propagation delay.

[0062] Blockchain based on Proof of Stake (PoS) mechanism, such as Ethereum after merge (Ethereum 2.0), Polygon, BNB Chain, Avalanche, etc. Such public chains elect validators to block through staking tokens, have the advantages of stable block, low energy consumption, and short confirmation time, but some implementations have the problems of too obvious concentration of verification nodes and limited timestamp precision.

[0063] In the system initialization phase, the platform can set N candidate chains as qualified target chains according to business needs and regulatory policies, and each chain configuration includes the following attributes:

[0064] Blockchain name (such as Ethereum, Polygon);

[0065] Network type (mainnet, testnet, private chain);

[0066] Consensus mechanism type (PoW, PoS, DPoS, PBFT, etc.);

[0067] Node RPC address and chain browser interface;

[0068] Block average block time, average confirmation time, transaction fee estimate, etc. Meta information;

[0069] Historical reliability indicators (such as number of reorganizations within a year, chain collapse records, etc.);

[0070] After setting is completed, the system will use this candidate chain list as the basis for subsequent chain state evaluation, risk scoring, and strategic broadcasting. In specific implementation, these chain information can be managed through configuration files, supporting hot updates, and the system can dynamically extend, replace, or suspend the participation of a chain at runtime. For example, when a public chain is attacked due to security vulnerabilities, network delay continues to rise, or frequent forks occur, the platform can temporarily exclude the chain and continue to execute the evidence storage process using the remaining chains.

[0071] It is worth mentioning that the present application does not limit the implementation details of the candidate chain or whether it is a consortium chain, public chain or private chain, the core is to support intelligent comparison and selection between multiple chains, and make dynamic decisions based on chain state feedback. In addition, in order to improve cross-chain data compatibility, the system adopts a unified hash digest standard, signature format (such as ECDSA) and transaction structure (JSONSchema) to ensure that the same contract digest can be repeatedly broadcast and verified consistently on multiple chains.

[0072] In order to realize intelligent risk assessment and multi-chain selection based on chain state, the present application provides a mechanism for collecting two core chain operation indicators in real time for each candidate blockchain network: transaction density index (OTDI) and network propagation lag (NPLS). These two indicators reflect the congestion level and network propagation stability on the chain, which are important inputs for subsequent risk model calculation.

[0073] In order to ensure that the calculation results have dynamic response ability and anti-noise characteristics, the present application introduces two different advanced algorithms to process the two types of data respectively.

[0074] The transaction density index represents the fluctuation degree of the number of transactions per unit time, which is used to measure the intensity of packaging competition and the congestion degree of the block.

[0075] Set the size of the sliding window to the last N blocks (such as N=20); get the number of transactions of the i-th block ; use the exponential weighted moving average (EWMA) method to calculate the mean: ; where λ∈(0,1), represents the smoothing coefficient (such as 0.3); calculate the dynamic standard deviation , that is, calculate the transaction density index OTDI, the expression is: ; in the formula, represents the standard deviation of the number of transactions of the i-th block.

[0076] For example: assuming that the number of transactions of the last five blocks of the Ethereum main chain is: [180, 190, 300, 280, 210]; using λ=0.3 initial mean =180, the transaction density index of the fifth block is calculated to be about 38.24, indicating that the current transaction volume fluctuation is high, which may be in the transaction congestion period or affected by the packet grabbing behavior.

[0077] The calculation method of network propagation lag NPLS includes:

[0078] NPLS represents the average time required for a transaction to be broadcast from the sending node to the majority of receiving nodes in the network to complete confirmation, reflecting the network synchronization ability and propagation stability.

[0079] ​The blockchain network is modeled as a directed graph G=(V, E), wherein the nodes V represent the full network master nodes, and the edges E represent the connection paths.

[0080] The starting time of the to-be-submitted transaction record is recorded , and the receiving time of each receiving node is recorded by listening to the P2P network Gossip protocol or receiving a confirmation event ; the propagation delay of each node is calculated , and the expression is ; the weight is allocated according to the node weight (such as hash power, voting weight, verifier level) , the network propagation lag is calculated, and the expression is ; n is the total number of nodes.

[0081] In order to solve the problem of evidence storage transaction rollback, failure or no record on the chain caused by factors such as blockchain network bifurcation, congestion or propagation delay, the present application introduces a chain selection model based on weighted risk score on the basis of obtaining the transaction density index (OTDI) and network propagation lag (NPLS) of the candidate blockchain, and combines with the intelligent broadcast strategy to realize the fault tolerance and optimal decision of evidence storage in the multi-chain environment.

[0082] The transaction density index and the network propagation lag are converted into a comprehensive feature vector, the comprehensive feature vector is taken as the input of a machine learning model, the machine learning model takes the risk score value label of each candidate chain as the prediction target, minimizes the sum of prediction errors of the risk score value labels of all candidate chains as the training target, trains the machine learning model until the sum of prediction errors converges, and stops the model training, and determines the risk score value R of each candidate chain according to the model output result, wherein the machine learning model is a polynomial regression model.

[0083] The system sets a plurality of risk level intervals according to the risk score result, and formulates corresponding broadcast strategies accordingly, which are as follows:

[0084]

[0085] The strategic broadcast mechanism is different from the static behavior of “submitting transactions immediately” in the traditional blockchain system, but introduces dynamic control strategies such as “adaptive delay of chain state, concurrent broadcast and priority switching”, which effectively improves the probability of evidence storage transactions entering the main chain and reduces the risk of transaction rollback due to falling into an isolated block.

[0086] The whole chain selection and broadcast process is as follows:

[0087] The chain state monitoring module is triggered at regular intervals to collect the OTDI and NPLS of each chain.

[0088] Calculate the risk score of each chain to form a priority list of candidate chains;

[0089] Select the chain with the lowest score as the main broadcast target chain;

[0090] If the main target chain is in the medium or high risk interval, then:

[0091] Set a transaction broadcast delay;

[0092] Select a second priority chain for concurrent backup broadcast;

[0093] Enable broadcast result callback to monitor the confirmation status on the chain;

[0094] Record the transaction hash, block number, etc. on the chain that confirms the transaction first, and mark this chain as the "main storage chain".

[0095] For example: Suppose there are currently three candidate chains: Ethereum, Polygon, and BNB Chain. The system detects the following data (simplified units):

[0096]

[0097] The system determines that the Polygon network has the lowest risk score, immediately broadcasts the transaction to it, and sets a delay broadcast to the Ethereum network as a backup path. Finally, the Polygon transaction gets 12 confirmations within 10 seconds and is confirmed as the main storage chain.

[0098] In the electronic contract blockchain storage method proposed in the present application, in order to improve the certainty and anti-fork ability of transaction storage, the system needs to continuously monitor the confirmation status of the transaction on these chains after broadcasting the storage transaction to multiple candidate blockchain networks, and select the first chain that reaches the set number of confirmations as the "main storage chain" of the electronic contract. This mechanism ensures that even if some transactions enter a dead block or are rolled back by the chain, there is still a chain that can serve as the final trusted chain to store contract data, greatly improving the robustness and legal credibility of the overall system.

[0099] The system maintains a set of listening modules for each candidate chain, which query and manage the status of broadcast transactions through the node interfaces (such as JSON-RPC, WebSocket, gRPC, etc.) provided by each blockchain network in real time. The listening content includes but is not limited to:

[0100] Whether the transaction has been successfully packaged into a block;

[0101] The block height of the block;

[0102] The number of blocks that have been confirmed (i.e. the number of blocks that have been added subsequently);

[0103] Block hash and transaction hash of the chain to which the transaction belongs.

[0104] For public chains such as Ethereum that support WebSocket, the eth_subscribe method can be used to listen to the packaging and confirmation progress of a specific transaction hash; for consortium chains such as Hyperledger Fabric, event logs and blockcommit events can be listened to.

[0105] In a blockchain notarization system, a transaction is still likely to be rolled back after being packaged into a block, especially in public chains that use proof of work (PoW) or proof of stake (PoS) mechanisms, so the transaction must wait for the block in which it is located to be confirmed by subsequent blocks to improve transaction irreversibility.

[0106] The present application sets a minimum confirmation block number threshold Cmin, for example, 12 confirmed blocks. That is, when 12 valid blocks are continuously added after the block in which the transaction is located, it is determined that the transaction has reached the "final confirmation state". This value can be flexibly adjusted according to the characteristics of the chain, for example:

[0107] Ethereum main network recommends 12 confirmations;

[0108] Polygon and other high-throughput chains recommend 20 confirmations;

[0109] Fabric consortium chains are generally set to 1-2.

[0110] During the listening process, the system listens to the status of all candidate chain transactions in an asynchronous manner and records the timestamp of each chain reaching the set number of confirmations. Define:

[0111] represents the time required for the i-th chain to confirm the transaction;

[0112] represents the timestamp of the i-th chain reaching the confirmation state;

[0113] represents the height of the block in which the transaction is located;

[0114] represents the transaction hash value on the chain.

[0115] The system selects the first chain that meets the confirmation condition from all chains as the main notarization chain and records the following key information:

[0116] Transaction hash: unique identifier of the transaction on the chain;

[0117] Block height: used to trace the block in which the transaction is located;

[0118] Block confirmation time: used to prove the time when the transaction reached consensus;

[0119] Chain ID and Network ID: Ensure the chain source is clear when querying and verifying in the future.

[0120] Storage level label: The main chain is marked as the main storage chain, and the rest of the chains can be marked as backup chains.

[0121] In the electronic contract signing method based on blockchain storage proposed in the present application, in order to ensure the traceability, verifiability and judicial audit ability of each electronic contract signing and storage process, the system needs to archive all key process data including storage chain, chain state score, transaction details after successful transaction confirmation. At the same time, in order to prevent storage failure caused by sudden abnormal situations such as chain transaction failure, network interruption or chain reorganization, the present application introduces off-chain supplementary storage and re-broadcast mechanism to build a set of blockchain storage redundancy system with disaster recovery and recovery ability.

[0122] When the storage transaction is successfully confirmed on a certain chain, the system will structure and persistently save all key information of this storage, including but not limited to the following fields:

[0123] Contract abstract hash value (i.e. unique identifier of the storage content on the chain);

[0124] Main storage chain identification (such as Ethereum, Polygon, etc.);

[0125] Transaction hash (unique hash value of the transaction on the chain);

[0126] Block height (i.e. the position of the transaction in the block);

[0127] Confirmation timestamp (for judicial authentication and time sequence proof);

[0128] Chain risk score value (for post-evaluation of chain selection rationality);

[0129] Alternative chain list and its risk score;

[0130] On-chain confirmation state summary (success / failure / rollback);

[0131] Algorithm version number and parameter configuration snapshot (to ensure future reproducible verification).

[0132] These information will be written into local database or distributed log storage system (such as IPFS+database index), and provide auditable interface for third-party verification, judicial audit or arbitration proof.

[0133] In actual operation process, the following several transaction failure or interruption scenarios may occur:

[0134] The transaction has not been packaged for a long time after broadcast;

[0135] The packaged transaction does not reach the set number of confirmation blocks;

[0136] The post-confirmation block is rolled back by the main chain;

[0137] Network disconnection or node loss response;

[0138] The transaction is rejected due to signature error or insufficient fee.

[0139] The system identifies the above-mentioned abnormal situations through the listening module and transaction state monitoring logic, and once it is confirmed that the transaction fails or times out without confirmation, it is considered that the evidence storage fails.

[0140] In the case of evidence storage failure, in order to protect the contract data from being lost and to prove that it has been attempted to be stored on the chain, the present application introduces an off-chain supplementary evidence storage mechanism. Specifically, it includes:

[0141] The contract hash is signed off-chain using a trusted timestamp service (such as an RFC 3161 timestamp server); the system generates an off-chain signature certificate, including the contract hash, timestamp, failed chain identifier, and failure reason; the certificate is digitally signed using the platform CA private key to ensure that the data is authentic, complete, and verifiable; the certificate is stored in an off-chain trusted database or a trusted third-party evidence storage platform; and the evidence storage status is marked as "off-chain supplementary pending retransmission". This mechanism ensures that even if the on-chain transaction fails, it can provide a certain degree of legal evidence as a backup.

[0142] After off-chain supplementary evidence storage, the system can reattempt on-chain broadcast according to the following logic:

[0143] Scheme One: preferentially rebroadcast to other low-risk chains;

[0144] Scheme Two: retry after the original chain network recovers (with a maximum number of retries);

[0145] Scheme Three: switch to a consortium chain, private chain, or L2 network for transitional evidence storage;

[0146] All rebroadcasts recalculate the ODTI and NPLS of the current chain, update the risk score, and apply the new broadcast strategy.

[0147] The system supports automatic backtracking to record chain failure history, avoiding repeated broadcasting to the same abnormal chain, and improving broadcast efficiency.

[0148] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto, and any person skilled in the art can easily think of changes or replacements within the technical scope disclosed in the present application, which should be covered within the protection scope of the present application.

Claims

1. A method for signing electronic contracts based on blockchain-based evidence storage, characterized in that: include: Obtain the raw data of the electronic contract to be signed, perform a hash operation on it, and generate a contract summary hash value; Multiple candidate blockchain networks are set as target chains for evidence storage, including public chains based on proof-of-work or proof-of-stake mechanisms; For each candidate blockchain network, the transaction density index and network propagation lag are collected in real time. The real-time transaction density index acquisition includes: setting the sliding window size to the most recent N blocks, and acquiring the transaction count of the i-th block. The mean is calculated using the exponentially weighted moving average method. Calculate the dynamic standard deviation That is, to calculate the transaction density index; The calculation method for Network Propagation Lag (NPLS) includes: modeling the blockchain network as a directed graph G=(V,E), where node V represents the network's master node and edge E represents the connection path; and determining the start time of the transaction record to be submitted. It also records the reception time of each receiving node by monitoring the Gossip protocol of the P2P network or receiving acknowledgment events. Calculate the propagation delay for each node. The expression is: ; Assign weights The network propagation lag is calculated using the following expression: n is the total number of nodes; The transaction density index and network propagation lag are input into the risk scoring model to calculate the comprehensive risk score for each candidate blockchain: Based on the comprehensive risk score, a strategic broadcast operation is performed on each candidate blockchain, including: when the risk score is lower than the first threshold, the contract digest hash value is immediately submitted to the corresponding blockchain; when the risk score is between the first threshold and the second threshold, the broadcast is delayed or broadcast to multiple chains simultaneously; when the risk score is higher than the second threshold, the submission is suspended and a backup mechanism is triggered. Monitor the transaction confirmation status of each target blockchain, select the first blockchain that reaches the set number of confirmations as the main evidence storage chain, and record the transaction hash, block height, and confirmation time. Archive the evidence storage results and chain state score records, and trigger off-chain supplementary evidence storage or rebroadcast in the event of evidence storage failure.

2. The electronic contract signing method based on blockchain evidence storage according to claim 1, characterized in that: Performing hash operations on the original data of electronic contracts includes: The uploaded electronic contract files are preprocessed, including character encoding standardization, dynamic field clearing, and content structuring. Read the processed contract file as a standard byte stream; A secure hash algorithm is used to encrypt the byte stream, generating a hash digest of fixed length. The hash digest, along with the hash algorithm identifier, processing rules, and version number, is encapsulated into a metadata structure.

3. The electronic contract signing method based on blockchain evidence storage according to claim 1, characterized in that: The transaction density index and network propagation lag are converted into a comprehensive feature vector. This comprehensive feature vector is used as the input to the machine learning model. The machine learning model aims to predict the risk score label of each candidate chain for each set of comprehensive feature vectors. The training objective is to minimize the sum of prediction errors for the risk score labels of all candidate chains. The machine learning model is trained until the sum of prediction errors converges, at which point the model training stops. The risk score R of each candidate chain is determined based on the model output. The machine learning model is a multinomial regression model.

4. The electronic contract signing method based on blockchain evidence storage according to claim 1, characterized in that: The process of monitoring transaction confirmation status and selecting the main certificate chain includes: Configure a listening channel for each candidate chain to monitor transaction status in real time through the blockchain node interface; Set a confirmation block threshold. When a transaction on a certain chain reaches the preset number of confirmation blocks, record its confirmation timestamp. Mark the first chain that meets the confirmation criteria as the main evidence storage chain; The transaction hash, block height, transaction confirmation time, and main chain identifier are recorded synchronously as evidence indexes.

5. The electronic contract signing method based on blockchain evidence storage according to claim 4, characterized in that: The steps for triggering off-chain supplementary evidence storage or rebroadcasting in the event of evidence storage failure include: Determine if a transaction is not confirmed on-chain within a specified time window or is rolled back by chain reorganization after being packaged; The timestamp service is invoked to generate an off-chain digital signature certificate, which contains a contract digest hash, a failed chain identifier, and a timestamp. Use the platform's private key to digitally sign the certificate and submit the certificate to a trusted off-chain evidence storage platform or database; Based on the current risk score, a low-risk candidate chain is selected, and the notarized transaction is constructed and broadcast again.

Images