Multi-version contract distribution and maintenance method for smart contract

Abstract

The invention belongs to the technical field of smart contracts, and discloses a multi-version contract distribution and maintenance method for a smart contract, and the method comprises the steps: firstly achieving the initial deployment, upgrading and safety verification of the smart contract, formally releasing the smart contract on a block chain after the verification is passed, and enabling the generated multi-version smart contract to be stored in the block chain; a system divides data sharing and access requests according to time and allocates the requests to intelligent contracts of corresponding versions for management, and the allocation and maintenance method specifically comprises the following steps: 1) version control and marking of multi-version contracts; 2) automatic detection of a request timestamp and contract selection; 3) contract routing logic and request distribution; 4) a multi-version parallel execution mechanism; 5) a compatibility and rollback mechanism; and 6) contract upgrading and storage management of old-version contracts. According to the method, the contract version performance and the system load can be dynamically optimized, the performance and the request success rate of different versions of contracts are monitored in real time by introducing a dynamic weight routing mechanism based on the multi-version contracts, and the contract priority is dynamically adjusted.

Description

Technical Field

[0001] The present invention belongs to the technical field of smart contracts, and specifically relates to a method for allocating and maintaining multi-version contracts for smart contracts. Background Art

[0002] Smart contracts involve blockchain technology. During the application process, smart contracts need to be upgraded and iterated according to requirements. However, there are still some problems in the existing technology regarding the upgrade of smart contracts, such as inflexible version management and load scheduling. Although old version contracts need to be phased out gradually, the current technology cannot dynamically allocate the priorities for upgrading guide contracts and phasing out different old version contracts according to actual needs, resulting in an overloaded system or bottlenecks during high concurrency, affecting the overall performance. Summary of the Invention

[0003] The purpose of the present invention is to provide a method for allocating and maintaining multi-version contracts for smart contracts, which is used to solve the technical problem in the existing technology that the priorities for upgrading guide contracts and phasing out different old version contracts cannot be dynamically allocated according to actual needs, resulting in an overloaded system or bottlenecks during high concurrency and affecting the overall performance.

[0004] The described method for allocating and maintaining multi-version contracts for smart contracts includes: First, implement the initial deployment, upgrade, and security verification of smart contracts. After passing the verification, officially release them on the blockchain to generate multi-version smart contracts. The system divides data sharing and access requests by time and allocates them to the corresponding version of smart contracts for management. The specific allocation and maintenance method includes:

[0005] 1) Version control and marking of multi-version contracts: The system marks the new version contracts generated after each contract upgrade and establishes a version number.

[0006] 2) Automatic detection of request timestamps and contract selection: When a data sharing or access request enters, the system automatically extracts the timestamp information of the request and checks the generation time of the request data.

[0007] 3) Contract routing logic and request allocation: When a request enters, the system runs an allocation logic module and automatically allocates the request to the appropriate contract version using preset routing rules.

[0008] 4) Multi-version parallel execution mechanism: Design a multi-version contract parallel execution mechanism to ensure that new and old version contracts can process requests simultaneously without interfering with each other.

[0009] 5) Compatibility and rollback mechanism: If the system detects compatibility problems or anomalies in the new version contract, the system will use the rollback mechanism to redirect the affected requests to the old version contract to avoid business interruption.

[0010] 6) Contract upgrade and storage management of old versions of contracts: Regularly clean up and optimize the data storage of old versions of contracts to ensure that the system does not have redundant data due to the parallel management of multiple contract versions.

[0011] Preferably, a dynamic weight routing mechanism based on multi-version contracts is introduced in the contract routing logic and request allocation. This method adjusts the priorities of different versions by real-time monitoring of the performance and request success rate of each version of the contract. The dynamic weight mechanism increases the weight of the version with better performance during high-frequency contract calls and transfers some low-priority requests to the older versions with lighter loads, thereby reducing the system load; the weight allocation formula of the dynamic weight routing mechanism is based on the following factors: version execution efficiency, success rate, and match degree with the request; the calculated weights are finally used to allocate requests among multi-version contracts. The higher the weight value, the higher the priority of the contract being selected; to adapt to the changing requirements in different business scenarios, the values of each parameter and coefficient in the weight allocation formula are dynamically adjusted.

[0012] Preferably, the weight allocation formula is as follows:

[0013] W = α·E + β·(1 - L) + γ·P + δ·R

[0014] In the formula, W represents the comprehensive weight value of the contract version, E represents the execution efficiency, which measures the response time or success rate of the contract version in processing data requests, and is set to a value between 0 and 1. The shorter the response time and the higher the success rate of the contract version, the closer the E value is to 1, and vice versa, the closer the E value is to 0; L represents the load status, which reflects the current load of the contract version and is usually measured by the number of requests or request frequency currently processed by this version, and is set to a value between 0 and 1. The higher the load, the closer the L value is to 1, and vice versa, the closer the L value is to 0; P represents the request priority, which is assigned a priority according to the urgency of the data request or business requirements, and is set to a value between 0 and 1. Urgent business requests are set with a higher priority, and the P value is close to 1, while ordinary business is set with a lower priority, and the P value is close to 0; R represents the compliance and risk factors, which refer to the security or compliance requirements involved in the data request and are set to a value between 0 and 1. Data requests with high compliance or high risk requirements will be assigned an R value close to 1, while ordinary data requests are close to 0; the coefficients α, β, γ, and δ respectively control the influence of execution efficiency, load, request priority, and compliance risk on the final weight, indicating the importance of the corresponding different parameters in the weight calculation.

[0015] Preferably, based on the compatibility and rollback mechanism of smart contracts, the method for realizing automatic rollback and compatibility maintenance includes the following steps:

[0016] 1) Before contract upgrade: Execute a complete contract test;

[0017] 2) After contract upgrade: Deploy a new version of the contract, activate the new contract functions, start monitoring the contract execution, and collect information such as performance data and exception logs of the new contract. Define threshold rules in the monitoring system. Once the set threshold is reached, trigger the rollback mechanism;

[0018] 3) Rollback trigger: After triggering the rollback mechanism, roll back to the historical contract version and restore to the stable state before the upgrade; Call the data mapping module to ensure data structure compatibility;

[0019] 4) Compatibility guarantee: Through the data conversion module, convert the data in the new version contract into the format of the old version; If there are structural differences between the new and old versions, use the compatibility layer to make the data flow unobstructed between different versions; In the case of coexistence of multiple contracts, data requests are automatically directed to the corresponding contract version according to the request time.

[0020] Preferably, the rollback trigger conditions include: When the contract is upgraded, if the system detects security vulnerabilities, performance degradation, abnormal events, or incompatibility with the old version in the new version contract, the system will trigger the rollback mechanism; The system uses an automated vulnerability scanning tool to regularly check for potential security vulnerabilities in the contract code. If serious security risks are found in the new contract, the rollback is triggered; Monitor the execution performance of the new contract, including processing speed, transaction throughput, and system response time. Once the performance of the new contract is lower than the set threshold, the system will initiate a rollback; A too high transaction failure rate or inconsistent data transmission belongs to an abnormal event, and the system determines whether to trigger a rollback according to the rules; There is an incompatibility between the new contract and historical data or the old version contract, triggering the rollback mechanism; Incompatibility includes contract parameter changes or data structure changes.

[0021] Preferably, the rollback mechanism: includes version snapshot and rollback execution, where,

[0022] Version snapshot: Before each contract upgrade, the system will automatically create a snapshot of the contract version and record the current state. During rollback, the system will restore to the previous stable version based on the snapshot data;

[0023] Rollback execution: When the rollback condition is triggered, the system automatically rolls back to the previous version, restores the initial state of the contract, and reactivates the old version contract.

[0024] Preferably, the compatibility and rollback mechanism involves compatibility maintenance and transition mechanisms, including:

[0025] 1) Data mapping and conversion: Design data mapping and conversion functions to ensure seamless data docking when rolling back to the old version contract;

[0026] 2) Compatibility during the transition period: During the activation of the old version contract, the system needs to ensure a smooth transition between the two; the old version contract continues to process historical data, while the new version contract takes over new data requests; through a dynamic routing mechanism, the system automatically determines which version of the contract the request should be directed to.

[0027] 3) Subsequent monitoring and auditing: Continue to monitor the running status of the old version contract to ensure its stable operation; record rollback events in the blockchain to form an immutable rollback record and audit trail.

[0028] 4) Algorithm support and optimization: The algorithms include compatibility algorithms and rollback algorithms.

[0029] 5) Recovery and protection after rollback: After rollback, the contract code and data are restored to the state of the previous version, and at the same time, all upgrade records and rollback events are recorded in the blockchain to ensure the transparency of operations.

[0030] Preferably, the compatibility algorithm includes: designing a rule-based data migration algorithm to automatically convert the data format in the new contract to a compatible format with the old version when the contract versions are incompatible; judging whether the request should be directed to the new version contract or the old version contract based on information such as the request timestamp and data generation time; realizing the parallel operation of the old and new versions through dynamic routing.

[0031] Preferably, the rollback algorithm includes: by monitoring the running status of the new contract in real time, using a threshold to judge whether to trigger a rollback; based on a risk scoring algorithm, evaluating risk factors such as the security and performance of the new contract, and automatically judging whether a rollback is needed.

[0032] The advantages of the present invention are as follows: The present invention can dynamically optimize the contract version performance and system load. By introducing a dynamic weight routing mechanism based on multi-version contracts, it monitors the performance and request success rate of different version contracts in real time and dynamically adjusts the contract priorities. When there are high-frequency calls, it preferentially selects the version with better performance, and assigns low-priority requests to the old version with lighter load, thereby effectively reducing the system load and improving the performance and stability of the overall system.

[0033] The present invention divides data sharing and access requests by time and assigns them to the smart contracts of the corresponding versions for management. The old version contract continues to process historical data, while the new version contract is used to manage new data and interactions. Ensure that data at different times follow the corresponding contract rules during access and sharing, and realize the continuity of contract logic. The management of multi-version contracts enables the old and new contracts to operate in parallel, without affecting the invocation and access of historical data, and at the same time ensures a smooth transition of contract upgrades.

[0034] The present invention realizes the automatic rollback and compatibility maintenance of old - version contracts. If security or performance issues are detected during the operation of the new contract version, the system can automatically perform a rollback operation and switch to the old - version contract to manage data. This process ensures the stability of data sharing and maintains business continuity while being compatible with new and old data structures. The stability of the system is ensured through the automated rollback mechanism, avoiding the impact of new - version failures on business continuity. The automated rollback mechanism enables the system to dynamically restore the contract version according to business requirements, reduces the risks after problems occur in the new contract, and supports the stable operation of data sharing. Brief Description of the Drawings

[0035] Figure 1 It is a schematic flow chart of a method for allocating and maintaining multi - version contracts for smart contracts according to the present invention. Detailed Embodiments

[0036] The following is a more detailed description of the specific embodiments of the present invention with reference to the accompanying drawings through the description of the embodiments, so as to help those skilled in the art have a more complete, accurate, and in - depth understanding of the inventive concept and technical solution of the present invention.

[0037] As Figure 1 shown, the present invention provides a method for allocating and maintaining multi - version contracts for smart contracts. First, the initial deployment, upgrade, and security verification of smart contracts are realized, and after passing the verification, they are officially released on the blockchain, thereby realizing the deployment and release of multi - version smart contracts.

[0038] For the multi - version smart contracts generated through the above steps, the system divides data sharing and access requests by time and allocates them to the smart contracts of the corresponding versions for management. The old - version contracts continue to process historical data, while the new - version contracts are used to manage new data and interactions. Ensure that data at different times follows the corresponding contract rules during access and sharing, and realize the continuity of contract logic. The management of multi - version contracts enables the old and new contracts to operate in parallel without affecting the invocation and access of historical data, and also ensures a smooth transition of contract upgrades. The specific content of the allocation and maintenance method is as follows.

[0039] 1) Version control and marking of multi - version contracts: The system marks the new - version contracts generated after each contract upgrade and establishes a version number (such as v1.0, v1.1, etc.). Each version has a specific creation timestamp for subsequent request routing. A contract version mapping table is established to associate each contract version with its applicable data time range. Version v1.0 can process data before 2023, while version v1.1 is applicable to data after 2023.

[0040] 2) Automatic Detection of Request Timestamps and Contract Selection: When a data sharing or access request enters the system, the system automatically extracts the timestamp information of the request and checks the generation time of the requested data. Based on the association between the timestamp and the mapping table, the system determines which version of the contract should handle the request. For example, a historical data request may point to an old version of the contract, while a request for the latest data points to the current version of the contract.

[0041] 3) Contract Routing Logic and Request Allocation: When a request enters the system, it runs an allocation logic module that automatically allocates the request to the appropriate contract version using predefined routing rules. This logic is similar to a load balancer but is based on the data generation time and version mapping relationship. The request allocation logic includes the following steps: extract the data generation time from the request, find the appropriate contract version through the mapping table, and route the request to the corresponding version of the contract for processing.

[0042] 4) Multi-Version Parallel Execution Mechanism: Design a multi-version contract parallel execution mechanism to ensure that new and old version contracts can handle requests simultaneously without interfering with each other. Each contract version has its own independent running space (such as independent functions and states) to avoid exceptions caused by data or logic conflicts.

[0043] In terms of technical implementation, virtual machine isolation or partitioning is used to achieve parallel execution, ensuring that the operations of each contract version do not interfere with each other. Parallel execution is achieved through multi-threading or multi-instance execution methods.

[0044] 5) Compatibility and Rollback Mechanism: If the system detects compatibility issues or exceptions in the new version of the contract, the system will use the rollback mechanism to redirect the affected requests to the old version of the contract to avoid business interruptions. Compatibility testing ensures that the new version of the contract can run in coordination with the old version before going live and meets the data access requirements at different time periods.

[0045] 6) Contract Upgrade and Storage Management of Old Version Contracts: Regularly clean up and optimize the data storage of old version contracts to ensure that the system does not cause redundant data due to the parallel management of multiple contract versions. Monitor the call frequency of old version contracts. If some old version contracts have not been called for a long time, transfer them to the archive library or gradually clean them up while ensuring that historical data will not be damaged.

[0046] In the contract routing logic and request allocation process, in order to improve the flexibility of version management, performance, and the precise matching of data requests, a dynamic weight routing mechanism based on multi-version contracts is introduced in the contract routing logic and request allocation. This method adjusts the priorities of different versions by monitoring the performance and request success rate of each version of the contract in real time. The dynamic weight mechanism can increase the weight of the version with better performance during high-frequency contract calls and transfer some low-priority requests to the older versions with lighter loads, thereby reducing the system load. The weight allocation formula of the dynamic weight routing mechanism can be based on the following factors: version execution efficiency, success rate, degree of match with requests, etc. The dynamic weight routing can not only effectively balance the loads of each contract version but also improve the system's response speed in a high-concurrency environment. The specific algorithm is as follows:

[0047] W = α·E + β·(1 - L) + γ·P + δ·R

[0048] In the formula, W represents the comprehensive weight value of the contract version. The system dynamically calculates the weight value W of each contract version and preferentially routes to the contract version with the highest weight according to the request requirements. The specific applications of the meanings of other variables are shown in the following specific descriptions.

[0049] 1) E (execution efficiency): Measures the response time or success rate of the contract version in processing data requests. Usually set as a value between 0 and 1. The closer the response time is to 0 and the success rate is to 1, the closer E is to 1; otherwise, it is closer to 0. A high execution efficiency will increase the weight of this contract, making it more likely to be selected. By setting the α coefficient, the influence of execution efficiency on the overall weight is controlled.

[0050] 2) L (load status): Reflects the current load situation of the contract version, usually measured by the number of requests or request frequency currently processed by this version. A value between 0 and 1. The higher the load, the closer L is to 1; the lower the load, the closer L is to 0. In the formula, (1 - L) indicates that the contract version with a lower load has a higher priority. As L increases, the value of W will decrease, thus avoiding overusing the contract version with a high load. By setting the β coefficient, the influence of execution efficiency on the overall weight is controlled.

[0051] 3) P (request priority): Assigns a priority to the data request according to the urgency of the request or business requirements. Emergency business requests (such as instant delivery) will be set with a higher priority, while ordinary business requests will be lower. The priority is set as a value between 0 and 1. For emergency requests, P is close to 1, and for ordinary requests, P is close to 0. The higher the priority, the higher the weight W of the contract version, to ensure that emergency business requests are given priority responses.

[0052] 4) R (Compliance and Risk Factors): Refers to the security or compliance requirements involved in a data request. Sensitive data requests or scenarios involving high security requirements will be assigned a higher R value. Range: Values between 0 and 1. Data requests with high compliance or high risk requirements will be assigned an R value close to 1, while ordinary data requests will be close to 0. Data requests with high compliance or risk requirements will be preferentially routed to a more secure contract version to enhance data security and compliance.

[0053] 5) Coefficients α, β, γ, and δ: Each coefficient corresponds to the importance of different parameters in weight calculation, and respectively controls the impact of execution efficiency, load, request priority, and compliance risk on the final weight. The coefficient values can be dynamically adjusted and configured based on different business scenarios, request types, or contract version characteristics. In case of emergency business, the value of γ can be increased to prioritize high-priority requests; in scenarios with high security and compliance requirements, the value of δ can be increased.

[0054] The calculated weight W is ultimately used to allocate requests among multiple version contracts. The higher the weight value, the higher the priority of the contract being selected. By dynamically adjusting the values of each parameter and coefficient, the system can flexibly adapt to the changing requirements in different business scenarios and balance performance, load, and security.

[0055] In the compatibility and rollback mechanism, to ensure the stability of the system and the consistency of data sharing, especially when security or performance issues occur in the new version contract, automated rollback and compatibility measures need to be taken. Among them, the trigger conditions and rollback mechanism of automatic rollback include the following.

[0056] 1) Rollback Trigger Conditions: When the contract is upgraded, if the system detects security vulnerabilities, performance degradation, abnormal events, or incompatibility with the old version in the new version contract, the system will trigger the rollback mechanism. The system uses automated vulnerability scanning tools to regularly check for potential security vulnerabilities (such as re-entrancy attacks, overflow vulnerabilities, etc.) in the contract code. If serious security hazards are found in the new contract, the rollback is triggered. Monitor the execution performance of the new contract, such as processing speed, transaction throughput, system response time, etc. Once the performance of the new contract is lower than the set threshold, the system will initiate a rollback. Excessive transaction failure rates, inconsistent data transmission, etc. are abnormal events, and the system will judge whether to trigger a rollback according to the rules. Incompatibility between the new contract and historical data or old version contracts, especially changes in contract parameters or data structures, triggers the rollback mechanism.

[0057] 2) Rollback Mechanism: Includes version snapshot and rollback execution.

[0058] Version Snapshot: Before each contract upgrade, the system will automatically create a snapshot of the contract version and record the current state. During rollback, the system will restore to the previous stable version based on the snapshot data.

[0059] Rollback Execution: When the rollback condition is triggered, the system automatically rolls back to the previous version, restores the initial state of the contract, and reactivates the old version contract.

[0060] Compatibility and rollback mechanisms involve compatibility maintenance and transition mechanisms to ensure good compatibility between new and old version contracts, so as to avoid data inconsistency or loss problems after rollback. The compatibility maintenance and transition mechanisms include the following.

[0061] 1) Data mapping and conversion: After the release of a new contract version, if the data structure or logic is changed, it may lead to incompatibility of historical data. To avoid historical data loss, data mapping and conversion functions are designed to ensure seamless data docking when rolling back to the old version contract. If new fields are added or the data format is modified in the new version contract, the rollback mechanism needs to convert and map the data according to the old version format to ensure data is not lost. When rolling back to the old version, the system triggers the data migration module to convert the data in the new version according to the old version structure, ensuring that data access is not affected.

[0062] 2) Transitional compatibility: During the activation period of the old version contract, the system needs to ensure a smooth transition between the two. The old version contract continues to process historical data, while the new version contract takes over new data requests. Through a dynamic routing mechanism, the system automatically determines which version of the contract the request should be directed to. During the rollback process, the transitional period of the contract should be transparent, minimizing the impact on the business process. The contract update log and version information will be made public in the blockchain for auditing and tracking.

[0063] 3) Subsequent monitoring and auditing: Continue to monitor the running status of the old version contract to ensure its continued stable operation. Record rollback events in the blockchain to form an immutable rollback record and audit trail.

[0064] 4) Algorithm support and optimization: The algorithms include compatibility algorithms and rollback algorithms, which are as follows.

[0065] Compatibility algorithm: Design a rule-based data migration algorithm to automatically convert the data format in the new contract to a compatible format with the old version when the contract versions are incompatible. Based on information such as the request timestamp and data generation time, determine whether the request should be directed to the new version contract or the old version contract. Achieve parallel operation of the old and new versions through dynamic routing.

[0066] Rollback algorithm: By real-time monitoring the running status of the new contract, use thresholds to determine whether to trigger a rollback. Based on a risk scoring algorithm, evaluate risk factors such as the security and performance of the new contract, and automatically determine whether a rollback is needed.

[0067] 5) Recovery and protection after rollback: After rollback, the contract code and data are restored to the state of the previous version, and all upgrade records and rollback events are recorded on the blockchain to ensure the transparency of the operation. Backup of contract historical versions: Each version after rollback can be restored through the backup mechanism to ensure the security of each historical version. After the contract is rolled back, the development team can fix the problems in the new version, test it again and then upgrade it to ensure the long-term security and stability of the contract.

[0068] Based on the compatibility and rollback mechanism of smart contracts, the method for realizing automatic rollback and compatibility maintenance includes the following steps.

[0069] 1) Before contract upgrade: Execute complete contract tests (including unit tests, integration tests, etc.). Conduct vulnerability scanning and performance benchmark testing on the contract to be upgraded. Record the snapshot of the current contract version, including contract code, data structure, status information, etc.

[0070] 2) After contract upgrade: Deploy the new version of the contract and start the new contract functions. Begin to monitor the contract execution situation and collect information such as performance data and exception logs of the new contract. Define threshold rules (such as exception events, performance metrics) in the monitoring system. Once the set threshold is reached, trigger the rollback mechanism.

[0071] 3) Rollback trigger: When performance problems, security vulnerabilities, and frequent exception events of the new version of the contract are detected, automatically start the rollback mechanism. Roll back to the historical contract version (i.e., the old version) and restore to the stable state before upgrade. Call the data mapping module to ensure data structure compatibility and that historical data will not be lost or incorrect due to different versions.

[0072] 4) Compatibility guarantee: Through the data conversion module, convert the data in the new version of the contract into the format of the old version. If there are structural differences between the new and old versions, use a compatibility layer (such as an adaptation layer) to ensure unobstructed data flow between different versions. In the case of coexistence of multiple contracts, data requests are automatically directed to the corresponding contract version according to the request time.

[0073] The present invention has been described exemplarily above in conjunction with the accompanying drawings. Obviously, the specific implementation of the present invention is not limited by the above methods. As long as various non-substantive improvements are made by adopting the inventive concept and technical solution of the present invention, or the inventive concept and technical solution of the present invention are directly applied to other occasions without improvement, they are all within the protection scope of the present invention.

Claims

1. A method for distributing and maintaining multiple versions of smart contracts, comprising: First, the initial deployment, upgrade and security verification of the smart contract are implemented, and after passing the verification, it is officially released on the blockchain. The generated multi-version smart contract is characterized by: the system divides data sharing and access requests by time and allocates them to the corresponding version of the smart contract for management. The allocation and maintenance method specifically includes: 1) Version control and marking of multi-version contracts: The system marks the new version of the contract generated after each contract upgrade and establishes a version number; 2) Automatic detection of request timestamps and contract selection: When a data sharing or access request comes in, the system automatically extracts the timestamp information of the request and checks the generation time of the requested data; 3) Contract routing logic and request allocation: When a request comes in, the system runs an allocation logic module and automatically allocates the request to the appropriate contract version using preset routing rules; 4) Multi-version parallel execution mechanism: Design a multi-version contract parallel execution mechanism to ensure that the old and new versions of the contract can process requests at the same time without interfering with each other; 5) Compatibility and rollback mechanism: If the system detects that the new version of the contract has compatibility issues or anomalies, the system will redirect the affected requests to the old version of the contract through the rollback mechanism to avoid business interruption; 6) Contract upgrades and storage management of old versions of contracts: Regularly clean up and optimize the data storage of old versions of contracts to ensure that the system does not cause redundant data due to the parallel management of multiple contract versions.

2. A method for distributing and maintaining a multi-version contract for a smart contract according to claim 1, characterized in that: A dynamic weight routing mechanism based on multi-version contracts is introduced in the contract routing logic and request allocation. This method adjusts the priority of different versions by real-time monitoring the performance and request success rate of each version of the contract. The dynamic weight mechanism increases the weight of the version with better performance when the contract is frequently called, and transfers some low-priority requests to the older version with lighter load, thereby reducing the system load. The weight allocation formula of the dynamic weight routing mechanism is based on the following factors: version execution efficiency, success rate, and matching degree with the request; The calculated weight is ultimately used to allocate requests among multiple versions of contracts. The higher the weight value, the higher the priority of the contract selection. In order to adapt to the changing needs in different business scenarios, the value of each parameter and coefficient in the weight allocation formula is dynamically adjusted.

3. A method for distributing and maintaining a multi-version contract for a smart contract according to claim 2, characterized in that: The weight distribution formula is as follows: W=α·E+β·(1-L)+γ·P+δ·R W in the formula represents the comprehensive weight value of the contract version. E represents execution efficiency, which measures the response time or success rate of the contract version in processing data requests. It is set to a value between 0 and 1. The shorter the response time and the higher the success rate of the contract version, the closer the E value is to 1, and vice versa. L represents load status, which reflects the current load status of the contract version. It is usually measured by the number of requests or request frequency currently processed by the version. It is set to a value between 0 and 1. The higher the load, the closer the L value is to 1, and vice versa. P represents request priority, which is assigned priority according to the urgency of the data request or business needs. It is set to a value between 0 and 1. Urgent business requests are given a higher priority, with a P value close to 1, while ordinary business requests are given a lower priority, with a P value close to 0. R represents the compliance and risk factor, which refers to the security or compliance requirements involved in the data request, and is set to a value between 0 and 1. Data requests with high compliance or high risk requirements will be given an R value close to 1, while ordinary data requests will be close to 0. The coefficients α, β, γ, and δ respectively control the impact of execution efficiency, load, request priority, and compliance risk on the final weight, indicating the importance of the corresponding parameters in the weight calculation.

4. According to claim 1, a method for distributing and maintaining multiple versions of smart contracts is characterized by: Based on the compatibility and rollback mechanism of smart contracts, the method for realizing automatic rollback and compatibility maintenance includes the following steps: 1) Before contract upgrade: perform complete contract testing; 2) After the contract is upgraded: deploy the new version of the contract, start the new contract function, start monitoring the contract execution, and collect the performance data, abnormal logs and other information of the new contract. Define the threshold rules in the monitoring system, and once the set threshold is reached, the rollback mechanism is triggered; 3) Rollback trigger: After the rollback mechanism is triggered, roll back to the historical contract version and restore to the stable state before the upgrade; Call the data mapping module to ensure data structure compatibility; 4) Compatibility guarantee: Through the data conversion module, the data in the new version of the contract is converted into the format of the old version; if there are structural differences between the new and old versions, the compatibility layer is used to ensure smooth flow of data between different versions; when multiple contracts coexist, data requests are automatically directed to the corresponding contract version according to the request time.

5. A method for distributing and maintaining multiple versions of smart contracts according to claim 4, characterized in that: The rollback trigger conditions include: after the contract is upgraded, if the system detects that the new version of the contract has security vulnerabilities, performance degradation, abnormal events, or is incompatible with the old version, the system will trigger the rollback mechanism; the system uses automated vulnerability scanning tools to regularly check for potential security vulnerabilities in the contract code. If the new contract is found to have serious security risks, a rollback is triggered; the execution performance of the new contract is monitored, including processing speed, transaction throughput, and system response time. Once the performance of the new contract is lower than the set threshold, the system will initiate a rollback; excessively high transaction failure rates and inconsistent data transmission are abnormal events, and the system determines whether the abnormal event triggers a rollback based on the rules; there is incompatibility between the new contract and historical data or the old version of the contract, triggering the rollback mechanism; incompatibility includes changes in contract parameters or changes in data structure.

6. A method for distributing and maintaining multiple versions of smart contracts according to claim 4, characterized in that: Rollback mechanism: includes version snapshot and rollback execution, among which, Version snapshot: Before each contract upgrade, the system will automatically create a snapshot of the contract version and record the current status. When rolling back, the system will restore to the last stable version based on the snapshot data; Rollback execution: When the rollback condition is triggered, the system automatically rolls back to the previous version, restores the initial state of the contract, and reactivates the old version of the contract.

7. A method for distributing and maintaining multiple versions of smart contracts according to claim 4, characterized in that: Compatibility and rollback mechanisms involve compatibility maintenance and transition mechanisms, including: 1) Data mapping and conversion: Design data mapping and conversion functions to ensure that data can be seamlessly connected when rolling back to the old version of the contract; 2) Transition compatibility: During the activation of the old version of the contract, the system needs to ensure a smooth transition between the two. The old version of the contract continues to process historical data, while the new version of the contract takes over new data requests. Through the dynamic routing mechanism, the system automatically determines which version of the contract the request should point to. 3) Subsequent monitoring and auditing: Continue to monitor the running status of the old version of the contract to ensure that the old version of the contract continues to run stably; record the rollback event in the blockchain to form an unalterable rollback record and audit trail; 4) Algorithm support and optimization: the algorithms include compatibility algorithms and rollback algorithms; 5) Recovery and protection after rollback: After rollback, the contract code and data are restored to the state of the previous version. At the same time, all upgrade records and rollback events are recorded in the blockchain to ensure the transparency of the operation.

8. A method for distributing and maintaining multiple versions of smart contracts according to claim 7, characterized in that: The compatibility algorithm includes: designing a rule-based data migration algorithm to automatically convert the data format in the new contract into a compatible format of the old version when the contract versions are incompatible; judging whether the request should be directed to the new version of the contract or the old version of the contract based on information such as the request timestamp and data generation time; and realizing parallel operation of the old and new versions through dynamic routing.

9. A method for distributing and maintaining multiple versions of smart contracts according to claim 7, characterized in that: The rollback algorithm includes: real-time monitoring of the running status of the new contract, using thresholds to determine whether a rollback is triggered; based on a risk scoring algorithm, evaluating risk factors such as the security and performance of the new contract, and automatically determining whether a rollback is required.

Images