A smart contract change method, device and medium based on a double ID design

Abstract

The application discloses a smart contract change method and device based on a double ID design and a medium, and relates to the technical field of smart contracts. The method comprises the following steps: in the case that a first content corresponding to a smart contract is changed on a client, an operation action of the change is acquired; all smart contracts of the first content are obtained by searching according to a life ID of the smart contract; a second smart contract is obtained by searching according to a standard type, and the standard type of the second smart contract is a formal version; an edited version of the second smart contract is obtained by automatically copying the second smart contract; the edited version of the second smart contract is changed and saved based on the client, a third smart contract is obtained, and the type standard of the second smart contract is updated to an informal version and saved. The method realizes that downstream business can be associated with all versions of the contract and directly traced to the current latest version of the contract, and the execution of the contract is easier to analyze.

Description

Technical Field

[0001] This application relates to the field of smart contract technology, and in particular to a smart contract modification method, device and medium based on dual ID design. Background Technology

[0002] The intelligentization of contract management systems is a crucial aspect of enterprise digitalization. Smart contract management systems, through digitalization, intelligentization, and collaboration, can improve the efficiency and accuracy of contract management, address pain points in traditional contract management, reduce contract risks, strengthen control over contracts, and enable the sharing of contract information, providing enterprises with better contract management and operational support.

[0003] Contract changes are a critical area in contract management where information omissions and data errors are common. With the development of computer application technology and advanced management concepts, the industry generally uses a full-change model to support contract change operations. However, the version management issues arising from this model have become a new challenge in the contract digitization process, particularly the high complexity of the relationships between different contract versions and downstream documents, and the difficulty in quickly and accurately analyzing contract execution. Software vendors generally use two methods: recording the previous version ID and using a change relationship record table. However, neither method solves the two problems mentioned above: recording the previous version ID results in different IDs for each version. Since downstream documents occur on different versions of the contract, the contract IDs recorded on downstream documents also differ. This makes it difficult to directly link a contract to all downstream documents, and vice versa. Instead, it requires searching version by version using intermediate version IDs, leading to significant performance issues. Using a change relationship record table also has these problems, and the search method requires looking up another table, further increasing complexity.

[0004] Based on the above analysis, the problems and shortcomings of the existing technology are as follows:

[0005] In existing technologies, after smart contract business changes generate multiple versions, it is difficult for downstream businesses to associate all versions with the current version, and it is not easy to analyze the contract execution status. Summary of the Invention

[0006] This application provides a smart contract modification method, device, and medium based on dual-ID design, which solves the problems in the prior art where multiple versions are generated after contract document modification, making it difficult for downstream businesses to associate all versions with the current version and making it difficult to analyze contract execution status.

[0007] In a first aspect, embodiments of this application provide a smart contract modification method based on a dual-ID design. The method includes: when a client modifies a smart contract corresponding to first content, obtaining the modification operation action. The smart contract includes dual IDs, a version number, and a type standard. The dual IDs include a contract ID and an origin ID. The contract ID is used to associate the business of the current smart contract, and the origin ID is used to associate the business of all smart contracts for the first content. The version number is used to record the number of times the smart contract has been modified. The standard type includes a formal version and an informal version. The method involves searching based on the origin ID of the smart contract to obtain all smart contracts for the first content; searching based on the standard type to obtain a second smart contract, where the standard type of the second smart contract is a formal version; automatically copying the second smart contract to obtain an edited version of the second smart contract; modifying and saving the edited version of the second smart contract based on the client to obtain a third smart contract, where the type standard of the second smart contract is updated to an informal version and saved.

[0008] In one implementation of this application, before obtaining the client's operation action to change the first smart contract, the method further includes: obtaining the client's operation action to add a smart contract with the first content; obtaining the first smart contract after the smart contract with the first content has been added and saved; assigning values ​​to the contract ID and identity ID of the first smart contract, incrementing the version number from 0, and setting the standard type to official version.

[0009] In one implementation of this application, after assigning values ​​to the contract ID and origin ID of the first smart contract, incrementing the version number from 0, and setting the standard type to official version, the method further includes: obtaining a second smart contract after modifying and saving the first smart contract, wherein the origin ID of the second smart contract remains unchanged, the contract ID is assigned a new value, the version number is incremented, and the type standard is official version; the type standard of the first smart contract is updated to unofficial version and saved.

[0010] In one implementation of this application, the method further includes: searching based on the smart contract's ancestry ID to find all smart contracts with the first content; sorting them by version number to obtain the second smart contract, wherein the second smart contract has the largest version number.

[0011] In one implementation of this application, the method further includes: obtaining all subsequent business of the smart contract of the first content based on the smart contract's ancestry ID; and grouping the smart contract of the first content according to its version number to obtain the content of each business change of the smart contract of the first content.

[0012] In one implementation of this application, the method further includes: after modifying the edited version of the second smart contract, sending the edited version of the second smart contract to the contract participants for verification; if the verification is successful, saving the edited version of the second smart contract, and the second smart contract automatically executing according to the modified business content.

[0013] In one implementation of this application, the official version is the latest version with the largest version number, while the unofficial version is used to retrospectively review the business content of the smart contract.

[0014] In one implementation of this application, the database field type of Contract ID and Personality ID is varchar(36), while the database field type of the type standard is varchar(1).

[0015] Secondly, embodiments of this application also provide a smart contract modification device based on a dual-ID design. The device includes at least one processor and a memory communicatively connected to the at least one processor. The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to: obtain the modification operation when a client modifies a smart contract corresponding to first content; the smart contract includes dual IDs, a version number, and a type standard; the dual IDs include a contract ID and an origin ID; the contract ID is used to associate the business of the current smart contract, the origin ID is used to associate the business of all smart contracts for the first content, the version number is used to record the number of modifications to the smart contract, and the standard type includes official and informal versions; search based on the origin ID of the smart contract to obtain all smart contracts for the first content; search based on the standard type to obtain a second smart contract, the standard type of which is an official version; automatically copy the second smart contract to obtain an edited version of the second smart contract; modify and save the edited version of the second smart contract based on the client's changes to obtain a third smart contract, the type standard of which is updated to an informal version and saved.

[0016] Thirdly, this application embodiment also provides a smart contract change non-volatile computer storage medium based on a dual-ID design, storing computer-executable instructions. The computer-executable instructions are configured to: when a client changes the smart contract corresponding to the first content, obtain the change operation action; the smart contract includes dual IDs, a version number, and a type standard; the dual IDs include a contract ID and an origin ID; the contract ID is used to associate the business of the current smart contract, the origin ID is used to associate the business of all smart contracts of the first content, the version number is used to record the number of changes to the smart contract, and the standard type includes a formal version and an informal version; search according to the origin ID of the smart contract to obtain all smart contracts of the first content; search according to the standard type to obtain a second smart contract, the standard type of the second smart contract being a formal version; automatically copy the second smart contract to obtain an edited version of the second smart contract; change and save the edited version of the second smart contract based on the client, to obtain a third smart contract, the type standard of the second smart contract being updated to an informal version and saved.

[0017] This application provides a smart contract modification method, device, and medium based on a dual-ID design, enabling downstream businesses to link information to all versions of the contract and directly trace back to the latest version, clearly and orderly displaying the contract modification history and quickly and conveniently collecting contract execution information. Since the origin ID of each version of the contract remains unchanged, subsequent businesses can easily link the origin IDs, making the association relationship simpler and the contract execution status easier to analyze. This greatly improves the efficiency of contract document version management and makes contract management more convenient. Attached Figure Description

[0018] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0019] Figure 1 A flowchart illustrating a smart contract modification method based on dual-ID design, provided as an embodiment of this application;

[0020] Figure 2 This is a schematic diagram of the internal structure of a smart contract modification device based on a dual-ID design, provided as an embodiment of this application. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0022] This application provides a smart contract modification method, device, and medium based on dual-ID design, which solves the problems in the prior art where multiple versions are generated after contract document modification, making it difficult for downstream businesses to associate all versions with the current version and making it difficult to analyze contract execution status.

[0023] The technical solutions proposed in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0024] Figure 1 This document provides a flowchart of a smart contract modification method based on a dual-ID design, as illustrated in an embodiment of this application. Figure 1 As shown in the figure, the smart contract modification method based on dual-ID design provided in this application embodiment specifically includes the following steps:

[0025] Step 10: When the client makes changes to the smart contract corresponding to the first content, obtain the change operation action. The smart contract includes dual IDs, version number and type standard. The dual IDs include contract ID and background ID. The contract ID is used to associate the business of the current smart contract, and the background ID is used to associate the business of all smart contracts of the first content. The version number is used to record the number of changes to the smart contract. The standard type includes formal version and informal version.

[0026] This application adopts a dual-ID model for smart contracts. A **Contract ID** field ensures the uniqueness of each smart contract or document, while a **Background ID** serves as the basis for identity authentication. Fields such as **Formal Contract Status** (i.e., type standard) and **Version Number** are used as auxiliary methods. This allows for quick and convenient identification, cross-referencing, and analysis of contracts even after multiple changes and version generation. This method ensures consistency in the identity of different contract versions, facilitates business connections, and makes cross-referencing and analysis of contracts more intuitive, resulting in smarter contract change management.

[0027] For example, after a purchase contract is signed, it may undergo multiple changes. The "Background ID" is similar to the design of a national ID card number in reality. That is, no matter how the contract or document is changed, just like a person can be quickly and accurately identified through the "Background ID" no matter what clothes they wear.

[0028] In the specific implementation of this step, the staff needs to modify the purchase contract with Company A (the purchase contract is the "first content" mentioned above). The "origin ID" of this purchase contract is "A", and "A" is entered into the corresponding smart contract system on the client side.

[0029] Understandably, the official version can be the latest version with the highest version number, while the unofficial version can be used to retrospectively review the business content of smart contracts.

[0030] A smart contract under a certain content may have multiple versions, but only one version can be used as the official version. That is, the latest version of the contract can be used for subsequent business and can continue to be changed according to business needs. The old version of the contract is the informal version. As a historical version, it is no longer used for subsequent business and cannot be changed again. It can only be archived as a historical version for future reference and business review.

[0031] In practice, the database field type for Contract ID and Background ID can be varchar(36), while the database field type for the type standard can be varchar(1).

[0032] When designing contract documents in a smart contract system, add fields such as Contract ID, Origin ID, Official Version, and Version Number to the contract data structure. The field information is as follows:

[0033]

[0034] Furthermore, the subsequent business data structure needs to record contract information as a relation, so it is necessary to add Contract ID (to record the origin ID of the associated contract) and Contract Version Number (to record the version number of the associated contract), as follows:

[0035] Contract ID ContractID varchar(36) Record the origin ID of related contracts Contract version number ContractVersion int Record the version number of the associated contract.

[0036] As an optional embodiment, before obtaining the client's action to trigger the change of the first smart contract, the method may further include:

[0037] Step 101: Obtain the operation action of the smart contract that adds the first piece of content on the client.

[0038] In practice, this step involves staff creating a procurement contract with Company A in the smart contract system.

[0039] Step 102: Once the smart contract for the first content is added and saved, the first smart contract is obtained.

[0040] In practice, this step involves creating and saving a purchase contract with Company A in the smart contract system, resulting in the first purchase contract.

[0041] Step 103: Assign values ​​to the contract ID and identity ID of the First Smart Contract, increment the version number from 0, and set the standard type to official version.

[0042] In the actual implementation of this step, after the procurement contract is created, the system assigns a new value to the [Contract ID] field, for example, [A], sets the [Background ID] field to [A], assigns 0 to the [Version Number] field, and assigns "Yes" to the [Is it a Formal Contract] field.

[0043] As another optional embodiment, after assigning values ​​to the contract ID and origin ID of the first smart contract, incrementing the version number from 0, and setting the standard type to official version, the method may further include:

[0044] Step 104: After modifying and saving the first smart contract, the second smart contract is obtained. The second smart contract retains its original ID, assigns a new value to the contract ID, increments the version number, and adopts the official version as its type standard.

[0045] In the specific implementation of this step, the staff needs to modify the purchase contract with Company A. After the modification is completed and saved, a second purchase contract with Company A is obtained. The [Origin ID] field of this purchase contract remains unchanged as [A], the [Contract ID] is [B], the [Version Number] field is 1, and the [Is it a formal contract] field is "Yes".

[0046] Step 105: Update the type standard of the first smart contract to an informal version and save it.

[0047] In this step, the "Is it a formal contract?" field of the first purchase contract with Company A is updated to "No", meaning it becomes a historical version and cannot be used for subsequent business transactions. The specific fields can be as follows:

[0048] A A 0 0 …… B A 1 0 …… C A 2 1 ……

[0049] Step 20: Search for all smart contracts with the first content based on the smart contract's ancestry ID.

[0050] In the specific implementation of this step, after the aforementioned staff enters [A] into the smart contract system corresponding to the client, they will obtain all procurement contracts associated with [A]: the first smart contract and the second smart contract, that is, the first procurement contract and the second procurement contract.

[0051] Step 30: Search according to the standard type to obtain the second smart contract. The standard type of the second smart contract is the official version.

[0052] In practice, staff will further filter based on whether the contract is official. Since only the latest version is official, the latest second procurement contract will be selected. Alternatively, staff can pre-set the filtering process so that the system directly filters the latest contract version related to the first content. When [A] is entered, the latest contract can be obtained without multiple filtering steps.

[0053] Step 40: Automatically copy the second smart contract to obtain an edited version of the second smart contract.

[0054] In practice, this step allows the system to directly copy the current procurement contract to generate a new version of the procurement contract, which is then in an editing state.

[0055] As another alternative embodiment, the method may further include:

[0056] Step 41: After making changes to the edited version of the second smart contract, send the edited version of the second smart contract to the contract participants for verification.

[0057] In practice, after the staff modifies the newly generated purchase contract, they send it to Company A, where relevant personnel review the contract.

[0058] Step 42: If the verification is successful, save the edited version of the second smart contract. The second smart contract will then be executed automatically according to the modified business content.

[0059] In this step, after Company A's relevant personnel expressed no objection, our staff saved the newly generated purchase contract, obtaining a second purchase contract. The system then automatically executed the business based on the content of the second purchase contract.

[0060] Step 50: Modify and save the edited version of the second smart contract based on the client to obtain the third smart contract. Update the type standard of the second smart contract to the informal version and save it.

[0061] In this step, after modifying and saving the newly generated purchase contract, a third purchase contract is obtained. The [Background ID] field remains unchanged at [A], the [Contract ID] is [C], the [Version Number] field is 2, and the [Is it a formal contract] field is "Yes".

[0062] Furthermore, the method may also include:

[0063] Step 20': Search for all smart contracts with the first content based on the smart contract's ancestry ID.

[0064] Step 30': Sort the contracts according to their version numbers to obtain the second smart contract, which has the largest version number.

[0065] In the actual implementation of this step, staff can sort the purchase contracts by their version number. Since the first purchase contract in the system has a version number of 0 and the second purchase contract has a version number of 1, they will see the second purchase contract with the largest version number.

[0066] Preferably, the method may further include:

[0067] Step 20: Obtain all subsequent business of the smart contract based on the smart contract's pedigree ID.

[0068] In practice, this step involves staff entering "[A]" into the corresponding smart contract system on the client side to obtain all procurement contracts associated with "[A]".

[0069] Step 30: Group the smart contracts of the first content according to their version numbers to obtain the content of each business change of the smart contracts of the first content.

[0070] In this step, subsequent business of the contract may occur during different versions of the contract. The subsequent business is associated with the [Background ID] and [Version Number]. When analyzing the contract, the corresponding subsequent business data is directly associated with the [Background ID] field.

[0071] In the actual implementation of this step, staff grouped the subsequent business according to their version numbers, obtaining the version number corresponding to each business. The summary of the subsequent business for Contract A is as follows:

[0072] Follow-up business 1 A 0 slightly Follow-up business 2 A 0 slightly Follow-up business 3 A 1 slightly Follow-up business 4 A 1 slightly Follow-up business 5 A 1 slightly Follow-up business 6 A 2 slightly Follow-up business 7 A 2 slightly

[0073] This solves the problem of the complex relationship between different versions of the contract and downstream documents, making it difficult to quickly and accurately analyze the contract execution status.

[0074] The above are embodiments of the method proposed in this application. Based on the same inventive concept, embodiments of this application also provide a smart contract modification device based on a dual-ID design, the structure of which is as follows: Figure 2 As shown.

[0075] Figure 2 This is a schematic diagram of the internal structure of a smart contract modification device based on a dual-ID design, provided as an embodiment of this application. Figure 2 As shown, the device includes:

[0076] At least one processor 201;

[0077] And a memory 202 that is communicatively connected to at least one processor;

[0078] The memory 202 stores instructions executable by at least one processor. These instructions are executed by at least one processor 201 to enable the at least one processor 201 to: obtain the change operation when the client changes the smart contract corresponding to the first content; the smart contract includes dual IDs, a version number, and a type standard; the dual IDs include a contract ID and an origin ID; the contract ID is used to associate the business of the current smart contract, the origin ID is used to associate the business of all smart contracts of the first content, the version number is used to record the number of changes to the smart contract, and the standard type includes formal and informal versions; search for all smart contracts of the first content based on the origin ID of the smart contract; search for the second smart contract based on the standard type, and the standard type of the second smart contract is formal version; automatically copy the second smart contract to obtain an edited version of the second smart contract; and modify and save the edited version of the second smart contract based on the client to obtain a third smart contract, and update the type standard of the second smart contract to informal version and save it.

[0079] Some embodiments of this application provide corresponding to Figure 1 A non-volatile computer storage medium for smart contract modification based on a dual-ID design stores computer-executable instructions. These instructions are configured to: when a client modifies a smart contract corresponding to first content, retrieve the modification action. The smart contract includes dual IDs, a version number, and a type standard. The dual IDs include a contract ID and an origin ID. The contract ID is used to associate the business of the current smart contract, and the origin ID is used to associate the business of all smart contracts related to the first content. The version number records the number of modifications to the smart contract. The standard type includes official and informal versions. The system searches based on the origin ID of the smart contract to obtain all smart contracts related to the first content. It then searches based on the standard type to obtain a second smart contract, whose standard type is official. The system automatically copies the second smart contract to obtain an edited version. Finally, the system modifies and saves the edited version of the second smart contract based on the client's actions to obtain a third smart contract, updating the type standard of the second smart contract to informal and saving it.

[0080] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments for IoT devices and media are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0081] The systems, media, and methods provided in this application are one-to-one correspondences. Therefore, the systems and media also have similar beneficial technical effects as their corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the systems and media will not be repeated here.

[0082] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0083] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0084] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0085] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0086] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0087] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0088] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0089] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0090] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A smart contract modification method based on dual-ID design, characterized in that, The method includes: When the client makes changes to the smart contract corresponding to the first content, the operation action of the change is obtained. The smart contract includes dual IDs, version number and standard type. The dual IDs include contract ID and origin ID. The contract ID is used to associate the business of the current smart contract. The origin ID is used to associate the business of all smart contracts of the first content. The version number is used to record the number of changes to the smart contract. The standard type includes formal version and informal version. Searching based on the origin ID of the smart contract yields all smart contracts containing the first content; Based on the standard type, a second smart contract is obtained, and the standard type of the second smart contract is the official version. The second smart contract is automatically copied to obtain an edited version of the second smart contract; The client modifies and saves the edited version of the second smart contract to obtain the third smart contract. The standard type of the second smart contract is updated to the informal version and saved. Before obtaining the client's action to trigger a change in the first smart contract, the method further includes: Retrieve the action of the smart contract that adds the first piece of content to the client; Once the smart contract for the first content is added and saved, the first smart contract is obtained; Assign values ​​to the contract ID and origin ID of the first smart contract, increment the version number from 0, and set the standard type to official version; After assigning values ​​to the contract ID and origin ID of the first smart contract, incrementing the version number from 0, and setting the standard type to official version, the method further includes: If the first smart contract is modified and saved, a second smart contract is obtained. The second smart contract retains the same origin ID, assigns a new value to the contract ID, increments the version number, and is of the standard type of official version. The standard type of the first smart contract is updated to an informal version and saved; The method further includes: after modifying the edited version of the second smart contract, sending the edited version of the second smart contract to the contract participants for verification; If the verification is successful, the edited version of the second smart contract is saved, and the second smart contract is automatically executed according to the modified business content.

2. The smart contract modification method based on dual-ID design according to claim 1, characterized in that, The method further includes: Search for all smart contracts with the first content based on the smart contract's ancestry ID; The second smart contract is obtained by sorting according to the version number, and the version number of the second smart contract is the largest.

3. The smart contract modification method based on dual-ID design according to claim 1, characterized in that, The method further includes: The smart contract for the first content is obtained based on the smart contract's ancestry ID; Grouping the smart contracts based on the version number of the first content yields the details of each business change in the smart contracts of the first content.

4. The smart contract modification method based on dual-ID design according to claim 1, characterized in that, The official version is the latest version with the highest version number, while the unofficial version is used to retrospectively review the business content of the smart contract.

5. The smart contract modification method based on dual-ID design according to claim 1, characterized in that, The database field type for Contract ID and Background ID is varchar(36), and the database field type for Standard ID is varchar(1).

6. A smart contract modification device based on dual-ID design, characterized in that, The device includes: At least one processor; And, a memory communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to: perform the steps of the smart contract modification method based on dual ID design as described in any one of claims 1-5.

7. A non-volatile computer storage medium for intelligent contract modification based on a dual-ID design, storing computer-executable instructions, characterized in that, The computer-executable instructions are configured to execute the steps of the smart contract modification method based on dual-ID design as described in any one of claims 1-5.

Images