WO2020206848A1

WO2020206848A1 - Method and device for smart contract upgrade, blockchain node device, and medium

Info

Publication number: WO2020206848A1
Application number: PCT/CN2019/093485
Authority: WO
Inventors: 周茂青
Original assignee: 深圳市网心科技有限公司
Priority date: 2019-04-11
Filing date: 2019-06-28
Publication date: 2020-10-15
Also published as: CN110018840A; CN110018840B

Abstract

A method and device for a smart contract upgrade, a blockchain node device, and a computer-readable storage medium, for solving the problem of replacement brought forth by the presence of two, a new and an old, contract addresses in the prior art. The present application does not deploy anew a new smart contract under a new contract address, but rather adds a correlation between an old contract address of the old contract and a new contract code of the new contract; because of the chain characteristic between blocks in a blockchain, when calling a smart contract, the correlation is always found in the nearest block, and the smart contract corresponding to the latest contract code is always called, and because only the correlation is modified, the contract address does not undergo any change, obviated is the need for a user to perform a replacement operation, and eliminated from the source is the uncontrollable factor of an address replacement being performed by the user, thus enhancing user experience for the user.

Description

Smart contract upgrade method, device, blockchain node equipment and medium

This application requires the priority of the Chinese patent application submitted to the Chinese Patent Office on April 11, 2019, with the application number 201910290052.X and the invention title "A smart contract upgrade method, device, blockchain node equipment and medium" Right, the entire contents of which are incorporated in this application by reference.

Technical field

This application relates to the field of smart contracts under blockchain technology, and in particular to a smart contract upgrade method, device, blockchain node equipment, and computer-readable storage medium.

Background technique

As the amount of data increases, the traditional centralized data management model exposes more and more problems. Single-node failure, scalability, maintenance, etc. are all important issues that restrict the further development of traditional centralized. Therefore, in order to solve these problems caused by centralization, blockchain technology based on the concept of decentralization has gradually entered the field of vision of the majority of users.

Blockchain technology was originally used to record every bitcoin transaction in the bitcoin network, which is a kind of accounting mechanism. With the development of technology, Ethereum has greatly expanded the blockchain by embedding smart contracts. The scope of application of the technology and the functions that can be achieved, but one of the characteristics of the blockchain technology is that the stored data cannot be completely deleted (unless you have a node device that can tamper with more than 50% of the entire blockchain network in a short time The ability to store data), when the content of the smart contract needs to be upgraded or revised, it cannot be directly replaced under the traditional mechanism.

The existing solution provided by Ethereum: separate the code logic and data of the smart contract to form two different contracts, namely the logic contract and the data contract, so as to realize the replacement of the implementation logic while keeping the data unchanged, thereby The business logic is upgraded separately. But the resulting problem is that the upgrade operation of the logic contract actually first needs to redeploy a new logic contract on the blockchain network. The new logic contract and the old logic contract each have their own contract address. Due to the change of the contract address , It is also necessary to guide all users who may call the smart contract to modify the contract address originally embedded in the application, otherwise the old smart contract corresponding to the old contract address will still be used, due to the need for users to complete the contract address update It is very high, and the degree of control over whether the user completes the update operation is not high, so it will bring a poor user experience to the user.

Therefore, how to solve the technical defects existing in the existing smart contract upgrade requirements as much as possible, and provide a more convenient, more controllable, and complete smart contract upgrade method without updating the contract address is an urgent need for those skilled in the art solved problem.

Summary of the invention

The purpose of this application is to provide a smart contract upgrade method, device, block chain node equipment, and computer readable storage medium, which aims to solve as much as possible the existing process of upgrading smart contracts due to the existence of two different contract addresses. The user needs to complete various problems caused by the replacement of the old and new contract addresses.

In order to achieve the above objectives, this application first provides a smart contract upgrade method, including:

Get smart contract upgrade request;

Determine the old contract address of the replaced old smart contract according to the smart contract upgrade request, and extract the new contract code of the new smart contract from the smart contract upgrade request;

Establish a corresponding relationship between the old contract address and the new contract code, and deploy the corresponding relationship in a newly formed block of the blockchain.

Optionally, obtain the smart contract upgrade request, including:

Obtain the smart contract upgrade request from the blockchain data pool.

Optionally, before establishing the correspondence between the old contract address and the new contract code, the method further includes:

Verify whether the smart contract upgrade request is legal;

Only when the smart contract upgrade request is legal, the step of establishing the correspondence between the old contract address and the new contract code is executed.

Optionally, the smart contract upgrade method further includes:

When the smart contract upgrade request is verified as not having legitimacy, the initiation information of the smart contract upgrade request is sent to the user who deployed the old smart contract.

Optionally, verifying whether the smart contract upgrade request is legal, including:

Verifying whether the user ID that initiated the smart contract upgrade request is consistent with the user ID that deployed the old smart contract;

If the user ID that initiated the smart contract upgrade request is consistent with the user ID that deployed the old smart contract, it is determined that the smart contract upgrade request is legal;

If the user ID that initiated the smart contract upgrade request is inconsistent with the user ID that deployed the old smart contract, it is determined that the smart contract upgrade request is not legal.

Extract the upgrade verification address list from the old smart contract; wherein a preset number of addresses are recorded in the upgrade verification address list;

Extracting signature information corresponding to the new smart contract from the smart contract upgrade request;

Judging whether the signature information can meet the requirement of the upgrade verification address list for the signature corresponding to the recorded address;

If the requirements are met, it is determined that the smart contract upgrade request is legal;

If the requirements are not met, it is determined that the smart contract upgrade request does not have legitimacy.

Optionally, the smart contract upgrade method further includes:

Receive smart contract call request;

Determine the target smart contract address according to the smart contract call request;

Determine the corresponding new contract code in the latest block deployed with the target smart contract address, and execute the new contract code to complete the smart contract call request.

In order to achieve the above objective, this application also provides a smart contract upgrade device, which includes:

The smart contract upgrade request obtaining unit is used to obtain the smart contract upgrade request;

The old contract address and the new contract code acquisition unit is used to determine the old contract address of the replaced old smart contract according to the smart contract upgrade request, and extract the new contract code of the new smart contract from the smart contract upgrade request;

The corresponding relationship establishment and deployment unit is used to establish the corresponding relationship between the old contract address and the new contract code, and deploy the corresponding relationship in the newly formed block of the blockchain.

Optionally, the smart contract upgrade request obtaining unit includes:

The block chain data pool obtaining subunit is used to obtain the smart contract upgrade request from the block chain data pool.

Optionally, the smart contract upgrade device further includes:

The legality verification unit is configured to verify whether the smart contract upgrade request is legal before establishing the correspondence between the old contract address and the new contract code;

The legality verification pass execution unit is configured to execute the step of establishing the correspondence between the old contract address and the new contract code only when the smart contract upgrade request is legal.

Optionally, the smart contract upgrade device further includes:

The illegal processing unit is configured to send the initiation information of the smart contract upgrade request to the user who deployed the old smart contract when the smart contract upgrade request is verified to be not legal.

Optionally, the legality verification unit includes:

The user ID consistency verification subunit is used to verify whether the user ID that initiated the smart contract upgrade request is consistent with the user ID that deployed the old smart contract;

The first legality determination subunit is configured to determine that the smart contract upgrade request is legal when the user ID that initiated the smart contract upgrade request is consistent with the user ID that deployed the old smart contract;

The first illegality determination subunit is used to determine that the smart contract upgrade request is not legal when the user ID that initiated the smart contract upgrade request is not consistent with the user ID that deployed the old smart contract.

Optionally, the legality verification unit includes:

The upgrade verification address list extraction subunit is used to extract the upgrade verification address list from the old smart contract; wherein a preset number of addresses are recorded in the upgrade verification address list;

A signature information acquisition subunit, configured to extract signature information corresponding to the new smart contract from the smart contract upgrade request;

The signature requirement required for the upgrade satisfies the judging subunit, which is used to judge whether the signature information can meet the requirement of the upgrade verification address list for the signature corresponding to the recorded address;

The second legality determination subunit is used to determine that the smart contract upgrade request is legal when the requirements are met;

The second illegality determination subunit is used to determine that the smart contract upgrade request does not have legality when the requirement is not met.

Optionally, the smart contract upgrade device further includes:

The smart contract call request receiving unit is used to receive the smart contract call request;

The target smart contract address determining unit is configured to determine the target smart contract address according to the smart contract call request;

The corresponding latest contract code determining and invoking unit is used to determine the corresponding new contract code in the latest block deployed and containing the target smart contract address, and execute the new contract code to complete the smart contract invocation request.

In order to achieve the above objective, the present application further provides a blockchain node device, the blockchain node device includes a memory, a processor, and a bus, and the memory stores an intelligence that can run on the processor. A contract upgrade program, where the smart contract upgrade program is transmitted to the processor by the bus, and when executed by the processor, the smart contract upgrade method as described in the above content is implemented.

In order to achieve the above objective, this application further provides a computer-readable storage medium on which a smart contract upgrade program is stored, and the smart contract upgrade program can be executed by one or more processors, In order to achieve the smart contract upgrade method described in the above content.

From the smart contract upgrade method provided in this application, it is obvious that in order to solve the replacement problem caused by the new and old contract addresses in the prior art, this application will not re-deploy the new smart contract under a new contract address , But to add the correspondence between the old contract address of the old smart contract and the new contract code of the new smart contract. Due to the chain characteristics of each block in the blockchain, the smart contract will always be called in the latest The corresponding relationship is found in the block of, so the smart contract corresponding to the latest contract code is always called, and because only the corresponding relationship is changed, the contract address has not changed, so the user does not need to perform replacement operations, from the source The uncontrollable factor of address replacement by the user is eliminated, thereby improving the user experience.

This application also provides a smart contract upgrade device, a blockchain node device and a computer-readable storage medium, which have the above-mentioned beneficial effects, and will not be repeated here.

Description of the drawings

In order to more clearly describe the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings that need to be used in the description of the embodiments or the prior art. Obviously, the drawings in the following description are only It is an embodiment of the present application. For those of ordinary skill in the art, other drawings can be obtained according to the provided drawings without creative work.

Figure 1 is a flowchart of a smart contract upgrade method provided by an embodiment of the application;

Figure 2 is a flowchart of another smart contract upgrade method provided by an embodiment of the application;

FIG. 3 is a flowchart of a method for verifying the legitimacy of an upgrade request based on a user ID in the smart contract upgrade method provided by an embodiment of the application;

4 is a flowchart of a method for verifying the legality of an upgrade request based on a signature in the smart contract upgrade method provided by the embodiment of the application;

FIG. 5 is a flowchart of a method for invoking a smart contract provided by an embodiment of the application;

FIG. 6 is a structural block diagram of a smart contract upgrade device provided by an embodiment of the application;

FIG. 7 is a schematic structural diagram of a blockchain node device provided by an embodiment of the application.

detailed description

In order to make the objectives, technical solutions, and advantages of the present invention clearer, the following further describes the present invention in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described here are only used to explain the present invention, but not to limit the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative work shall fall within the protection scope of the present invention.

The terms "first", "second", "third", "fourth", etc. (if any) in the specification and claims of this application and the above-mentioned drawings are used to distinguish similar objects, without having to use To describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances so that the embodiments described herein can be implemented in an order other than the content illustrated or described herein. In addition, the terms "including" and "having" and any variations of them are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to the clearly listed Those steps or units may include other steps or units that are not clearly listed or are inherent to these processes, methods, products, or equipment.

It should be noted that the descriptions related to "first", "second", etc. in the present invention are only for descriptive purposes, and cannot be understood as indicating or implying their relative importance or implicitly indicating the number of technical features indicated. . Therefore, the features defined with "first" and "second" may explicitly or implicitly include at least one of the features. In addition, the technical solutions between the various embodiments can be combined with each other, but it must be based on what can be achieved by a person of ordinary skill in the art. When the combination of technical solutions is contradictory or cannot be achieved, it should be considered that such a combination of technical solutions does not exist. , Is not within the protection scope of the present invention.

Example one

Please refer to FIG. 1. FIG. 1 is a flowchart of a smart contract upgrade method provided by an embodiment of the application, which includes the following steps:

S101: Obtain a smart contract upgrade request;

This step is to obtain the smart contract upgrade request for subsequent smart contract upgrades.

One way to obtain the smart contract upgrade request, including but not limited to, is to obtain the smart contract upgrade request from the blockchain data pool in the blockchain network. Since the blockchain network is usually used to store transaction data, the blockchain data pool is also usually called a transaction data pool. Among them, various requests initiated by users uploaded through each blockchain node device will be aggregated into the data pool. When it is necessary to upgrade an old smart contract that has been deployed on the blockchain network to For a new smart contract, the upgrade party will initiate a smart contract upgrade request to the blockchain network through the blockchain node device, so that the blockchain network can obtain the smart contract upgrade request from the blockchain data pool. The smart contract upgrade is completed in response to the smart contract upgrade request.

Among them, in order to complete the upgrade of the smart contract, the smart contract upgrade request usually includes at least the content of the new smart contract (ie code or different forms of code, such as bytecode that is easy to be executed by the computer after compilation, etc.) and needs to be replaced , The relevant information of the upgraded old smart contract (such as the most important contract address). Of course, according to all possible special requirements in actual application scenarios, relevant information such as legality verification, time stamps, and other information or data used to achieve special requirements can also be included in the smart contract upgrade request or with the The smart contract upgrade request is sent together and uploaded to the blockchain data pool.

S102: Determine the old contract address of the replaced old smart contract according to the smart contract upgrade request, and extract the new contract code of the new smart contract from the smart contract upgrade request;

On the basis of S101, this step aims to determine two parameters according to the smart contract upgrade request. One is the contract code of the new smart contract. This step and subsequent steps will use the "new contract code" to refer to; the second is the new contract code. The smart contract corresponds to the contract address of the old smart contract that has been deployed in the blockchain network and needs to be upgraded and replaced. This step and subsequent steps will use the "old contract address" to refer to.

To deepen understanding, examples will be used to illustrate:

In actual situations, smart contract calls are implemented through smart contract call requests initiated by users. This is because the smart contract call request contains the address of the target smart contract that the user needs to call, that is, the target contract address, and each smart contract When the contract is deployed to the blockchain network, the corresponding relationship between the contract address and the contract code will be established, so that after the target contract address is extracted from the smart contract call request, the corresponding contract can be successfully called according to the corresponding relationship Code, and implement the smart contract function by executing the contract code.

Expressed in the form of Key-Value (key-value pair) that is, the contract address is Key, and the contract code is Value. When each smart contract is deployed on the blockchain network, the correspondence between Key and Value has been established. In this step, one is the value of the new smart contract and the other is the key of the old smart contract. Assuming that Key1 represents the contract address of the old smart contract, and Value1 represents the contract code of the old smart contract, it is not upgraded Before, the corresponding relationship between contract address and contract code was: Key1—Value1.

S103: Establish a corresponding relationship between the old contract address and the new contract code, and deploy the corresponding relationship in the newly formed block of the blockchain.

On the basis of S102, this step aims to establish the corresponding relationship between the old contract address and the new contract code, and deploy the corresponding relationship in the newly formed block of the blockchain. Following the previous example, the contract code of the new smart contract determined according to the smart contract upgrade request can be represented by Value2, so the operation performed in this step is to establish the correspondence between Key1 and Value2, and deploy the new correspondence in the latest In the formed block, users can successfully call the upgraded smart contract code without replacing Key1 with Key2 in their own applications.

It should be noted that the corresponding relationship between the old contract address and the new contract code established in this application is a new operation of the corresponding relationship, rather than a traditional replacement operation, only due to the non-deletable feature of the blockchain Yes, but there will not be call confusion because Key1 corresponds to the two contract addresses of Value1 and Value2 at the same time. Because of the chain relationship and atomicity between the blocks in the blockchain, when a smart contract is called, there will always be The corresponding relationship is called in the nearest block, so based on the fact that the new smart contract must be deployed on the blockchain network later than the old smart contract, the new smart contract must be deployed after the block where the old smart contract is located. In the block, based on this situation, the corresponding relationship cannot be modified in time, there is a one-to-many situation, and there will be no problems in the execution and call process.

Further, since any user in the blockchain network can initiate a smart contract upgrade request, in order to prevent malicious attackers from using this mechanism to disrupt the normal function of the smart contract, it is also possible to add a smart contract upgrade request before the new correspondence takes effect. The legality verification mechanism to eliminate the above hidden dangers through the legality verification steps. Depending on the actual situation, legality verification can be achieved in a variety of specific ways. For example, it can be achieved by judging whether the initiating users of the new and old smart contracts are the same user, or by signing, public and private key mechanisms, etc. A similar mechanism can be implemented, and the most suitable method can be flexibly selected according to the specific situation, and there is no specific limitation here.

Example two

Please refer to Figure 2. Figure 2 is a flowchart of another smart contract upgrade method provided in an embodiment of the application. It is different from Embodiment 1. This embodiment considers the security of smart contract upgrades. On the basis, the legality verification steps for the smart contract upgrade request are added, and a specific implementation method is given, including the following steps:

S201: Obtain a smart contract upgrade request;

S202: Determine the old contract address of the replaced old smart contract according to the smart contract upgrade request, and obtain the new contract code of the new smart contract from the smart contract upgrade request;

S203: Verify whether the smart contract upgrade request is legal, if yes, execute S205, otherwise execute S204;

In this embodiment, the verification of the validity of the smart contract upgrade request is placed after S202, before S204 and S205, and after S202, because some parameters or data obtained in step S202 are needed to implement the legality verification step of S203. If it is not necessary to execute S202 to determine whether the smart contract upgrade request is legal, it can also be placed after S201 and before S202.

S204: Send the initiation information of the smart contract upgrade request to the user who deployed the old smart contract;

This step is based on the verification result of S203 that the smart contract upgrade request is not legal. In this case, this embodiment provides a specific follow-up processing method, which is to send the initiation information of the smart contract upgrade request For users deploying old smart contracts, the initiation information should include which user initiated the smart contract upgrade request, and by telling this part of the information to users who have the right to upgrade the old smart contract to inform them that there are users trying Modify the smart contract that you have deployed. Furthermore, the blockchain network can also issue a warning to fake users after verifying this behavior, and the serious ones can be added to the blacklist.

S205: Establish a corresponding relationship between the old contract address and the new contract code, and deploy the corresponding relationship in the newly formed block of the blockchain.

This step is based on the verification result of S203 that the smart contract upgrade request is legal. Therefore, the corresponding relationship between the old contract address and the new contract code will be added on this basis, and subsequent deployment operations will be completed.

Example three

Please refer to Figure 3. Figure 3 is a flowchart of a method for verifying the legitimacy of a user ID-based upgrade request in the smart contract upgrade method provided in an embodiment of the application. On the basis of the second embodiment, this embodiment provides a A specific method for verifying the legality of a smart contract upgrade request includes the following steps:

S301: Verify whether the user ID that initiated the smart contract upgrade request is consistent with the user ID that deployed the old smart contract, if yes, execute S302, otherwise execute S303;

S302: Determine that the smart contract upgrade request is legal;

S303: Determine that the smart contract upgrade request is not legal.

It can be seen from the above content that this application here provides a method for judging whether the smart contract upgrade request is legal based on the user ID, that is, by judging the user who initiated the smart contract upgrade request and the user who deployed the old smart contract Whether it is the same user to determine whether the smart contract upgrade request is legal, because the upgrade operation is often limited to the original author's implementation, and upgraders who are not the original author are usually regarded as counterfeiters. It should be noted that the user ID described here is a feature information that can be used to uniquely identify a blockchain user. It can be called differently in different application scenarios, such as user address, user identification code, user feature code, etc. , Within the scope of the idea of this step, all should belong to the protection scope of this application.

It should also be noted that the legality verification method based on the user ID is more suitable for individual deployment users, that is, there are usually no other approved users to perform smart contract upgrade operations.

Different from the legality judgment method suitable for individual deployment users shown in Figure 3, this application also provides the user ID-based legality verification method for upgrade requests as shown in Figure 4, which is suitable for team deployment users. The address upgrade verification address list can flexibly set the number of address corresponding signatures required to pass legality verification, so that users who deploy non-old smart contracts can also complete smart contract upgrade operations through this mechanism, including the following steps:

S401: Extract the upgrade verification address list from the old smart contract;

Among them, the upgrade verification address list records a preset number of addresses. It should be noted that the multiple addresses recorded are suitable for the legality verification of the upgrade. Check whether the smart contract upgrade request carries the required number or The signature given by the address of the object completes the verification.

S402: Extract the signature information corresponding to the new smart contract from the smart contract upgrade request;

This step is based on the fact that the signature information is also included in the smart contract upgrade request.

S403: Determine whether the signature information meets the requirements of the upgrade verification address list for the signature corresponding to the recorded address, if it meets the requirements, execute S404, otherwise execute S405;

Specifically, this requirement can be flexibly set according to the actual situation, such as setting the signature of more than the preset number of addresses, the signature of certain specific addresses, and even each item that needs to be recorded in the upgrade verification address list. The signature corresponding to the address can be flexibly selected according to all the special requirements that may exist in the actual situation, and there is no specific limitation here.

S404: Determine that the smart contract upgrade request is legal;

S405: Determine that the smart contract upgrade request is not legal.

This embodiment provides two legality verification methods suitable for different scenarios through Figure 3 and Figure 4 respectively. Of course, it does not mean that there are no other implementation solutions besides these two methods. The above two solutions are only for common A feasible solution exists in the application scenario.

Example four

Please refer to Figure 5. Figure 5 is a flow chart of a smart contract invocation method provided by an embodiment of this application. It shows how the user can invoke the smart contract through the same contract address after the smart contract upgrade method provided in any of the above embodiments corresponding to this application. The process of completing the target operation to the new contract code includes the following steps

S501: Receive a smart contract call request;

S502: Determine the target smart contract address according to the smart contract call request;

S503: Determine the corresponding new contract code in the latest block deployed and containing the target smart contract address, and execute the new contract code to complete the smart contract call request.

It should also be noted that this application only addresses the scenario where the smart contract runs in the virtual machine of the blockchain service process content, and does not address other scenarios.

Because the situation is complicated, it is impossible to enumerate one by one. Those skilled in the art should be aware that there can be many examples based on the basic method and principle provided in this application combined with the actual situation. Without paying enough creative work, they should all be included in this application. Within the scope of protection.

Example five

Please refer to FIG. 6. FIG. 6 is a structural block diagram of a smart contract upgrade device provided by an embodiment of the application. The device may include:

The smart contract upgrade request obtaining unit 100 is configured to obtain the smart contract upgrade request;

The old contract address and new contract code acquisition unit 200 is used to determine the old contract address of the replaced old smart contract according to the smart contract upgrade request, and extract the new contract code of the new smart contract from the smart contract upgrade request;

The correspondence relationship establishment and deployment unit 300 is used to establish the correspondence relationship between the old contract address and the new contract code, and deploy the correspondence relationship in the newly formed block of the blockchain.

Wherein, the smart contract upgrade acquiring unit 100 may include:

Further, the smart contract upgrade device may also include:

The legality verification unit is used to verify whether the smart contract upgrade request is legal before establishing the correspondence between the old contract address and the new contract code;

The legality verification passes the execution unit and is used to execute the step of establishing the correspondence between the old contract address and the new contract code only when the smart contract upgrade request is legal.

Furthermore, the smart contract upgrade device may also include:

The illegal processing unit is used to send the initiation information of the smart contract upgrade request to the user who deployed the old smart contract when the smart contract upgrade request is verified to be not legal.

Wherein, the legality verification unit may include:

The first legality determination subunit is used to determine that the smart contract upgrade request is legal when the user ID that initiated the smart contract upgrade request is consistent with the user ID that deployed the old smart contract;

The first illegality determination subunit is used to determine that the smart contract upgrade request is not legal when the user ID that initiated the smart contract upgrade request is inconsistent with the user ID that deployed the old smart contract.

Wherein, the legality verification unit may include:

The upgrade verification address list extraction subunit is used to extract the upgrade verification address list from the old smart contract; among them, the upgrade verification address list records a preset number of addresses;

The signature information acquisition subunit is used to extract the signature information corresponding to the new smart contract from the smart contract upgrade request;

The signature requirements required for the upgrade meet the judging subunit, which is used to determine whether the signature information can meet the requirements for the signature corresponding to the recorded address in the upgrade verification address list;

The second legality determination subunit is used to determine the legality of the smart contract upgrade request when the requirements are met;

The second illegality determination sub-unit is used to determine that the smart contract upgrade request is not legal when the requirements are not met.

Further, the smart contract upgrade device may also include:

The target smart contract address determination unit is used to determine the target smart contract address according to the smart contract call request;

The corresponding latest contract code determination and calling unit is used to determine the corresponding new contract code in the latest block deployed with the target smart contract address, and execute the new contract code to complete the smart contract call request.

This embodiment exists as a device embodiment corresponding to the above method embodiment. The above functional units are also described and explained in the above method embodiment. As it corresponds to the method embodiment, this embodiment also has a method embodiment. All the beneficial effects of, will not be repeated here.

In the above, some embodiments have been used to describe in detail how to call the new contract code through the original contract address without the need for the user to replace the address of the upgraded new smart contract. This application also provides a method corresponding to this method. The physical hardware device of this part corresponds to the solution part. The implementation principle is not repeated here. The hardware composition of the physical hardware device will be described below. Please refer to Figure 7, which is an embodiment of the application. A schematic diagram of the structure of a blockchain node device provided:

The blockchain node device 400 includes a memory 410, a processor 420, and a bus 430. The memory 410 stores a smart contract upgrade program that can run on the processor 420, and the smart contract upgrade program is transmitted to the processor 420 through the bus 430. , And when executed by the processor 420, each step in the smart contract upgrade method described in the above embodiment can be implemented.

The memory 410 includes at least one type of readable storage medium. The readable storage medium includes flash memory, hard disk, multimedia card, card-type memory (for example, SD or DX memory, etc.), magnetic memory, magnetic disk, and optical disk. The memory 410 may be an internal storage unit of the blockchain node device 400 in some embodiments, such as a hard disk of the blockchain node device 400. In some other embodiments, the memory 410 may also be an external storage device of the blockchain node device 400, such as a plug-in hard disk or a smart media card (SMC) equipped on the blockchain node device 400, Secure Digital (SD) card, Flash Card, etc. Further, the memory 410 may also be composed of an internal storage unit and an external storage device at the same time. Further, the memory 410 can be used not only to store various application software and various data installed in the blockchain node device 400, but also to temporarily store data that has been output or will be output.

In some embodiments, the processor 420 may be a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chips, and is used to run program codes or process data stored in the memory 410 , Such as smart contract upgrade procedures.

The bus 430 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of presentation, only one bidirectional hollow indicator line is used in Fig. 7, but it does not mean that there is only one bus or one type of bus.

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware or any combination thereof. In the several embodiments provided in this application, it should be understood that the disclosed system, device, and method may be implemented in other ways. For example, the device embodiments described above are merely illustrative, for example, the division of units is only a logical function division, and there may be other divisions in actual implementation, for example, multiple units or components can be combined or integrated. To another system, or some features can be ignored, or not implemented. In addition, the displayed or discussed mutual coupling or direct coupling or communication connection may be indirect coupling or communication connection through some interfaces, devices or units, and may be in electrical, mechanical or other forms.

The units described as separate components may or may not be physically separate, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the objectives of the solutions of the embodiments.

In addition, the functional units in each embodiment of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units may be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or software functional unit.

If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer readable storage medium. Based on this understanding, the technical solution of this application essentially or the part that contributes to the existing technology or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium , Including several instructions to make a computer device (which can be a personal computer, a server, or a network device, etc.) execute all or part of the steps of the method given in each embodiment of the present application. The aforementioned storage media include: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), magnetic disk or optical disk and other media that can store program code .

It should be noted that the sequence numbers of the above-mentioned embodiments of the present invention are only for description, and do not represent the advantages and disadvantages of the embodiments. And the terms "include", "include" or any other variants thereof in this article are intended to cover non-exclusive inclusion, so that a process, device, article or method including a series of elements not only includes those elements, but also includes The other elements listed may also include elements inherent to the process, device, article, or method. If there are no more restrictions, the element defined by the sentence "including a..." does not exclude the existence of other identical elements in the process, device, article or method that includes the element.

The above are only the preferred embodiments of the present invention, and do not limit the scope of the present invention. Any equivalent structure or equivalent process transformation made by using the contents of the description and drawings of the present invention, or directly or indirectly applied to other related technical fields , The same reason is included in the scope of patent protection of the present invention.

Claims

A smart contract upgrade method, characterized in that it includes:

Get smart contract upgrade request;

Determine the old contract address of the replaced old smart contract according to the smart contract upgrade request, and extract the new contract code of the new smart contract from the smart contract upgrade request;

Establish a corresponding relationship between the old contract address and the new contract code, and deploy the corresponding relationship in a newly formed block of the blockchain.
The smart contract upgrade method according to claim 1, wherein obtaining a smart contract upgrade request includes:

The smart contract upgrade request is extracted from the blockchain data pool.
The smart contract upgrade method according to claim 1, wherein before establishing the correspondence between the old contract address and the new contract code, it further comprises:

Verify whether the smart contract upgrade request is legal;

Only when the smart contract upgrade request is legal, the step of establishing the correspondence between the old contract address and the new contract code is executed.
The smart contract upgrade method according to claim 3, further comprising:

When the smart contract upgrade request is verified as not having legitimacy, the initiation information of the smart contract upgrade request is sent to the user who deployed the old smart contract.
The smart contract upgrade method according to claim 3, characterized in that verifying whether the smart contract upgrade request is legal, comprises:

Verifying whether the user ID that initiated the smart contract upgrade request is consistent with the user ID that deployed the old smart contract;

If the user ID that initiated the smart contract upgrade request is consistent with the user ID that deployed the old smart contract, it is determined that the smart contract upgrade request is legal;

If the user ID that initiated the smart contract upgrade request is inconsistent with the user ID that deployed the old smart contract, it is determined that the smart contract upgrade request is not legal.
The smart contract upgrade method according to claim 3, characterized in that verifying whether the smart contract upgrade request is legal, comprises:

Extract the upgrade verification address list from the old smart contract; wherein a preset number of addresses are recorded in the upgrade verification address list;

Extracting signature information corresponding to the new smart contract from the smart contract upgrade request;

Judging whether the signature information can meet the requirement of the upgrade verification address list for the signature corresponding to the recorded address;

If the requirements are met, it is determined that the smart contract upgrade request is legal;

If the requirements are not met, it is determined that the smart contract upgrade request does not have legitimacy.
The smart contract upgrade method according to any one of claims 1 to 6, characterized in that it further comprises:

Receive smart contract call request;

Determine the target smart contract address according to the smart contract call request;

Determine the corresponding new contract code in the latest block deployed with the target smart contract address, and execute the new contract code to complete the smart contract call request.
A smart contract upgrade device, characterized in that it includes:

The smart contract upgrade request obtaining unit is used to obtain the smart contract upgrade request;

The old contract address and the new contract code acquisition unit is used to determine the old contract address of the replaced old smart contract according to the smart contract upgrade request, and extract the new contract code of the new smart contract from the smart contract upgrade request;

The corresponding relationship establishment and deployment unit is used to establish the corresponding relationship between the old contract address and the new contract code, and deploy the corresponding relationship in the newly formed block of the blockchain.
A block chain node device is characterized in that it comprises:

Memory, used to store computer programs;

The processor is configured to implement the smart contract upgrade method according to any one of claims 1 to 7 when executing the computer program.
A computer-readable storage medium, wherein a computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, the smart contract upgrade according to any one of claims 1 to 7 is realized method.