CN115098518A

CN115098518A - Chain upgrading method for four-layer intelligent contract

Info

Publication number: CN115098518A
Application number: CN202210641206.7A
Authority: CN
Inventors: 杜志强; 傅妍芳; 成昊; 马益帆
Original assignee: Xian Technological University
Current assignee: Xian Technological University
Priority date: 2022-06-08
Filing date: 2022-06-08
Publication date: 2022-09-23
Anticipated expiration: 2042-06-08
Also published as: CN115098518B

Abstract

The invention discloses a chain upgrading method of a four-layer intelligent contract, which comprises the following steps: i proxy layer contracts, which are used for providing a calling link facing a user; m business layer contracts are used for realizing business logic; n storage layer contracts used for realizing data structure definition and data storage and developed based on precompiled contracts and oriented to a base table; j verification layer contracts are used for performing chain verification on the contracts; the method comprises the following steps: deploying the new version to the blockchain; receiving a contract upgrading request, wherein verification parameters can specify verification layer contracts required by verifying a new version, and agent parameters can specify agent layer contracts required by upgrading; and calling a verification layer contract through the specified agent layer contract to verify the new version, updating the version address and destroying the old version. The invention can realize low-cost chain upgrading on the intelligent contract, and particularly performs low-cost chain upgrading on the data structure definition and the data storage mode in the intelligent contract.

Description

Chain upgrading method for four-layer intelligent contract

Technical Field

The invention belongs to the technical field of block chains, and particularly relates to a chain upgrading method for a four-layer intelligent contract.

Background

In a broad sense, blockchains can be described as a novel application mode of technologies such as distributed storage, encryption algorithms, and consensus mechanisms. The block chain technology uses the concept of transaction in the financial field, each transaction will affect the data on the chain, the transaction is packed in a block, and a new block is connected with the previous block. The block chain comprises a plurality of blocks which are connected together in series by using the chain to form the block chain; the blocks are used for recording metadata and transaction information of the blocks, and the chains ensure the sequence of the blocks. The block comprises a block head and a block body, the block head records metadata of the block, the metadata comprises a time stamp, a block Hash (Hash) value, a Hash value of a previous block, a random number and the like, the block body records a certain amount of transaction information, and the blocks are connected through the Hash value to form a block chain.

The block chain has three main characteristics: (1) decentralization: the traditional centralized system depends on a trusted environment, needs an authoritative central authority, the block chain is maintained by all nodes in the network together, the change of the state on each chain needs the consent of most participants, and the stable operation of the system is realized through an encryption algorithm and a consensus mechanism; (2) non-tamper-able and traceable: and the hash values of the communication blocks among the blocks are linked and arranged according to the practical sequence. Calculating and chain structure according to the hash value of the block to make the block chain have the property of being not tampered; according to the irreversibility of time, the block chain has the characteristic of traceability; (3) sharing and transparency of information: each node in the blockchain network stores all data on the chain, users in the network can share information, and all data can be seen by all users.

The basic architecture of the blockchain is divided into six layers: (1) and (3) a data layer: the method is used for solving the problem of how to form the block by the data, and comprises a block structure, a chain structure, a cryptographic algorithm and the like; (2) network layer: the system is used for solving the problem of point-to-point interaction of users without a centralized server, and comprises a P2P (peer-to-peer) networking, a data propagation and verification mechanism; (3) a consensus layer: the method is used for solving the problem of data consistency on the chain and coping with network attacks, and the conventional consensus algorithm comprises workload certification, rights and interests certification, practical Byzantine fault tolerance and the like; (4) excitation layer: a mechanism for encouraging nodes to participate in billing, including the issuance and distribution of rewards; (5) and (3) contract layer: the system is used for realizing the programmable characteristic of the block chain and completing the automatic execution of service logic on the chain; (6) an application layer: the method is used for realizing the floor application of the block chain, from digital currency to the financial industry and then to all walks of society.

Wherein, the contract layer is mainly used for deploying intelligent contracts. An intelligent contract is defined as a computer program that implements the terms of the contract. Since it was difficult to guarantee the correct execution of computer programs in non-fully trusted environments before blockchain technology emerged, smart contracts began to receive widespread attention until the appearance of bitcoin in 2008. As a bottom layer technology of the bit currency, the characteristics of decentralized block chain, trust removal and data non-tampering are conformed to the requirements of an intelligent contract on an operation platform.

The Etherhouse which appeared in 2013 provides an intelligent contract programming language with complete Tuoling, supports complex business logic, and enables intelligent contracts to be gradually applied to multiple fields. The subsequent enterprise-level alliance chain project Hyperledger Fabric and the block chain underlying technology platform FISCO BCOS developed by cooperation of multiple enterprises in China have good support for intelligent contract language with complete image.

The working principle of the intelligent contract of the block chain is divided into three steps: (1) the intelligent contract is established through the mutual negotiation of the multi-party participating main bodies, and the participating main body registration information generates a public key and a private key corresponding to the contract. The public key is disclosed to the outside, and only can the party obtain the corresponding private key, and the private key is not disclosed to the outside, and the private key is used for the electronic contract signature. (2) The established intelligent contract is transmitted into an executable block chain environment, the execution process crosses the guarantee of a third-party platform, the input cost in the program is reduced, the efficiency of contract verification and program execution is improved, the credible and transparent transaction is realized, and a whole network consensus is achieved, namely the system nodes in the whole transaction do not need to establish mutual trust. Once triggered, the consensus mechanism proceeds through a series of valid verifications. (3) After the block chain deploys the intelligent contract, the intelligent contract is automatically executed according to the program code in the distributed environment.

Because the tamper-proof characteristic of the block chain, after the cochain is deployed in the intelligent contract, the change cannot be carried out when the contract has a leak or needs change, the traditional solution is to re-deploy a complete contract and cochain, and the upgrading mode has three problems:

(1) the original life cycle of the intelligent contract is destroyed, and a new life cycle of the intelligent contract can be restarted after the new contract is deployed;

(2) the new contract data and the old contract data are incompatible, and the data of the old contract needs to be subjected to integral data migration;

(3) redeploying a new contract may result in an address update of the contract that affects the normal invocation of the user.

In order to solve the above problems, in a closest prior art, liuyunxian et al propose a loose coupling three-layer structure intelligent contract model independent of a block chain platform in "loose coupling model research facing to upgrade on intelligent contract chain", which is hereinafter referred to as a three-layer contract model for short. The three-layer contract model divides the traditional intelligent contract into three subsets, namely an interface contract set, a service contract set and a data contract set; the interface contract calls a service contract to realize service logic; the service contract mainly comprises contract function codes, contract states (issuing/deploying/enabling/executing), execution progress and the like, the transaction of each participant can be realized through the function codes, the execution content and the state of the transaction are tracked, and finally, the result is returned to the interface contract. The service contract calls a data contract to realize interaction with data on the chain, and the data contract (also called a storage contract) defines a data structure and data access operation, is mainly used for storing general data and an instance set including participants, authorities, logs, keys, configuration and the like, historical application data and the like of the general data and the instance set, and permanently stores various data. By separating the business logic from the contract interface and the definition and storage of data, the problems (1) and (3) in the three problems can be effectively solved.

When contract business needs to be expanded or a contract has a bug, the specific upgrading process of the intelligent contract designed based on the three-layer contract model is as follows:

(1) a transaction request initiated by a user or DApp (Decentralized Application) is firstly linked to an interface contract, the interface contract judges the type of the request, and the service contract is selected to be called or upgraded according to the type of the transaction request;

(2) if the business contract is a common business request, the interface contract calls a corresponding business contract to complete response, and a result value returned by the business contract is stored in a data contract and then returned to the DApp or the user;

(3) if the business contract is an updating transaction request, firstly updating the logical contract and redeploying the new-version business contract to the block chain, then calling the updating function in the interface contract and linking the interface contract to a new logical contract address, and finally automatically linking the interface contract to the new business contract for the user when the user needs to call the updated intelligent contract;

(4) and finally, the interface contract returns the result value after the transaction is completed to the user or the DApp.

However, in the three-layer contract model, the data contract stores and acquires data through global variables, so in order to realize the reusability of the data contract, different versions of service contracts are inherited in the same data contract, that is, corresponding service logic data are stored in the same data contract. Therefore, when the data contract has an upgrading requirement, a large amount of data migration work is still required, namely, the data in the data contract of the old version is completely migrated into the new version, so that the three-layer contract model cannot perform low-cost chain upgrading on the data contract, namely, cannot perform low-cost chain upgrading on the data structure definition and the data storage mode.

Disclosure of Invention

In order to solve the problems in the prior art, the invention provides a chain upgrading method of a four-layer intelligent contract.

The technical problem to be solved by the invention is realized by the following technical scheme:

a chain upgrading method for a four-tier intelligent contract, the four-tier intelligent contract comprising: i proxy layer contracts, M service layer contracts, N storage layer contracts and J verification layer contracts, wherein I is more than or equal to 1, J is more than or equal to 1, M is more than or equal to 1, and N is more than or equal to 1; the agent layer contract is used for providing a user-oriented calling link for the four-layer intelligent contract; the business layer contract is used for realizing business logic of the four-layer intelligent contract; the storage layer contract is used for realizing data structure definition and data storage in the business layer contract, and the storage layer contract is a contract which is developed based on a precompiled contract and faces a base table; the verification layer contract is used for performing on-chain verification on the four-layer intelligent contract;

the chain upgrading method comprises the following steps:

deploying a new version of a target contract to be updated to the blockchain; wherein the target contract is a service layer contract or a storage layer contract in the four-layer intelligent contract;

receiving a contract upgrading request; the contract upgrading request carries a new version address and an old version address of the target contract, and also carries agent parameters and verification parameters related to the upgrading; wherein the verification parameters are used for specifying J e [1, J ] verification layer contracts required for verifying the new version of the target contract; the agent parameters are used for specifying I e [1, I ] agent layer contracts required for upgrading the target contract;

validating the new version at the new version address by invoking a first one of the I e [1, I ] proxy layer contracts, the J e [1, J ] validation layer contracts;

updating an old version address of the target contract to a new version address and destroying the old version at the old version address by a second one of the I e [1, I ] proxy layer contracts.

Optionally, when the target contract is about a storage tier contract, the chain promotion method further comprises:

updating the address of a storage layer contract corresponding to the related service layer contract through a third proxy layer contract in the I E [1, I ] proxy layer contracts;

wherein the relevant business tiers are approximately: and performing contracts of data structure definition and data storage by using the target contract.

Optionally, the verifying the layer contract, the mode of performing chain verification on the four-layer intelligent contract, includes:

and performing on-chain verification on the four-layer intelligent contract by adopting a mode of assertion rollback and last line rollback.

Alternatively, a single proxy-layer contract can provide user-oriented invocation links for the following contracts:

one or more business layer contracts, or, alternatively, one or more verification layer contracts.

Alternatively, a single verification-layer contract can verify the following contracts:

one or more business tier contracts, or, alternatively, one or more storage tier contracts.

Optionally, a single storage tier contract can perform data structure definition and data storage on data of one or more business tier contracts;

data of a single business tier contract can be data structure defined and data stored by one or more storage tier contracts.

Optionally, the precompiled contract is a precompiled contract in a FISCO BCOS.

Optionally, the chain upgrade method further comprises:

and verifying the identity of the user initiating the contract upgrading request so as to continuously execute the chain upgrading method when the verification is passed.

Optionally, the chain upgrading method further includes:

and after the old version address of the target contract is updated to the new version address and the old version at the old version address is destroyed, storing the updated process information on the chain to the block chain.

Optionally, the N verification-layer contracts include one or more of:

detecting contracts of contract integrity, detecting contracts of contract boundary values, detecting contracts of abnormal flows in the contracts, detecting contracts of contract key points and verifying and upgrading related information;

wherein the contract key is a pre-specified key contract content.

In the chain upgrading method of the four-layer intelligent contract provided by the invention, the intelligent contract is designed into a four-layer structure of a proxy layer, a business layer, a storage layer and a verification layer according to the idea of attention point separation, and each layer of contract can be designed into a plurality of sub-contracts. Therefore, the contracts in each layer and the same layer are independent, componentization is realized, the influence on other contracts caused by redeployment of a single contract is reduced, and the engineering requirements of the intelligent contracts are well adapted. Compared with a data layer contract in the existing three-layer contract model, the storage layer contract is developed based on the precompiled contract and oriented to the base table, so that the decoupling of the relation between the storage layer contract and the service layer contract is realized, the visibility of the storage layer contract is weakened, the local complexity and the data migration cost of the contract are reduced, and the low-cost chain upgrading and contract version compatibility of the storage contract can be realized. In addition, before the intelligent contract is upgraded, the multi-angle verification can be performed on the new version by calling the verification layer contract, so that chain vulnerabilities are effectively detected, and the security of intelligent contract upgrading is enhanced.

The present invention will be described in further detail with reference to the accompanying drawings.

Drawings

FIG. 1 is internal and external logic for a four-tier intelligent contract in an embodiment of the present invention;

FIG. 2 is a flowchart of a chain upgrading method for a four-layer intelligent contract according to an embodiment of the present invention;

fig. 3 is a flowchart of another chain upgrading method for a four-layer intelligent contract according to an embodiment of the present invention.

Detailed Description

The present invention will be described in further detail with reference to specific examples, but the embodiments of the present invention are not limited thereto.

In order to realize low-cost chain upgrading of an intelligent contract, particularly low-cost chain upgrading of definition and a storage mode of data in the intelligent contract, the embodiment of the invention provides a chain upgrading method of a four-layer intelligent contract. In the method, the intelligent contract to be upgraded comprises four layers: the system comprises an agent layer, a business layer, a storage layer and a verification layer. For each four-layer intelligent contract, the four-layer intelligent contract comprises I agent layer contracts, M service layer contracts, N storage layer contracts and J verification layer contracts, wherein I is larger than or equal to 1, J is larger than or equal to 1, M is larger than or equal to 1, and N is larger than or equal to 1.

The agent layer contract is used for providing a user-oriented calling link for the four-layer intelligent contract; the business layer contract is used for realizing the business logic of the four-layer intelligent contract; the storage layer contract is used for realizing data structure definition and data storage in the business layer contract, and the storage layer contract is a contract which is developed based on a precompiled contract and faces a base table; the verification layer contract is used for performing on-chain verification on the four-layer intelligent contract, and specifically performs on-chain verification on a target contract to be upgraded in the four-layer intelligent contract each time.

Referring to fig. 1, a four-layer architecture of an intelligent contract in an embodiment of the present invention is applied to a contract layer in a block chain infrastructure, and an application layer of a block chain interacts with a data layer of the block chain through the contract layer of the block chain; the application layer is DAPP, and the data layer uses a block and a state database for storage.

As shown in fig. 1, the user request is forwarded to the contract layer after the DAPP classification processing of the application layer, the contract layer receives the request from the contract of the proxy layer, the contract of the proxy layer calls the contract of the service layer or the contract of the verification layer, and finally the storage layer contract initiates a transaction to the block chain of the data layer, and accesses the state database of the block chain.

Specifically, the request received by the proxy layer contract may be a common request sent by a user, and the proxy layer contract adapts the request to the corresponding service layer contract; when the request is an upgrading request sent by a user, the request is adapted to a corresponding verification layer contract to carry out verification, and then the contract address is updated to be linked to a new version contract. Therefore, the agent layer contracts have the characteristic of polymorphism, and can be linked to different implementation contracts by calling different contract updating functions.

It will be appreciated that the proxy layer contract is a unified entry to the four-layer intelligent contract, hiding implementation and upgrade details from the user, and does not affect the user's normal calls during upgrade.

The service layer contract mainly comprises functions of on-chain service logic processing, transaction definition, calling storage contract and the like; and realizing the transaction of each participant through the service logic, tracking the execution state of the transaction, and finally returning the result to the proxy layer contract.

The storage layer contract is used for permanently storing data of the business layer contract, abstracting the layer into a form of a base table, and calling in a Structured Query Language (sql) mode to realize compatibility of new and old contracts. Each storage tier contract contains two parts of content, a general base table operation and a definition of a data structure.

Specifically, in the embodiment of the present invention, the storage tier contract stores and acquires data using a precompiled contract; since the precompiled contract is embedded in the system source code before the start of the blockchain system, any contract after the start of the blockchain system can call the precompiled contract, and thus, data compatibility can be realized. Once the data is compatible, each contract can access the data, and data migration is not needed, so that upgrading cost is low.

In contrast, after the traditional contract and the intelligent contract with the existing three-layer architecture are redeployed, the former contract data cannot be accessed, the contract before function call needs to be written, and the data stored in the global variable in the former contract is stored in the global variable of the new contract, so that the overall migration of the data is performed, and the upgrading cost is high.

Alternatively, the precompiled contract may be a precompiled contract in a FISCO BCOS, but is not limited thereto. The FISCO BCOS is a block chain bottom platform and is a platform for upgrading modules and remodeling functions on the basis of a BCOS open source platform by a financial block chain cooperation alliance open source working group by taking financial business practices as reference samples.

The precompiled contract in the FISCO BCOS provides a method for writing a contract by using C + +, the contract logic is separated from data, the performance is better than that of a solid contract, and the contract upgrading can be realized by modifying the bottom code. Wherein, solid is a contractual programming language of Ethereum (etherhouse), whose syntax is similar to JavaScript language, and is intended to be localized to the etherhouse virtual machine.

The precompiled contract in the FISCO BCOS is compared with the solid contract, the address of the precompiled contract is fixed and is defined in the code, and the address of the solid contract can be determined after the address is deployed; precompiled contract data is stored in a table, separated from the contract, contract logic can be upgraded, and solidity contract variables and data are stored in an MPT tree; the precompiled contract C + + bottom layer is executed, the performance is higher, parallel execution can be realized, and the solidity contract is limited by the EVM virtual machine and can only be executed in series.

The CRUD interface realized based on the precompiled contract simplifies the cost of migrating mainstream SQL-oriented business application to a block chain, is similar to the traditional business development mode, reduces the contract development and learning cost, only needs to care about core logic for the contract, and is separated from storage and calculation, thereby facilitating the contract upgrade; and the data storage adopts distributed storage, so that the efficiency is higher. The CRUD interface refers to an adding (Create) interface, a retrieving (Retrieve) interface, an updating (Update) interface and a deleting (Delete) interface during calculation processing.

In practice, the block verifier at the node determines the type based on the address of the invoked contract when performing the transaction. Addresses 1-4 represent ether house precompiled contracts, addresses 0x1000-0x10000 are C + + precompiled contracts, and other addresses are solidity contracts. When executing a precompiled contract, firstly, acquiring an object of the precompiled contract according to a contract address, wherein each precompiled contract object can realize a call interface, the specific logic of the precompiled contract is realized in the interface, and the call interface acquires a Function Selector (Function Selector) and parameters according to the ABI (application Binary interface) code of a transaction and then executes the corresponding logic. Each precompiled contract must implement its own call interface, which contains three parameters: context: save context of transaction execution, _ param: parameter information of the invocation contract, _ origin: a transaction sender for authority control.

The verification layer contract is mainly used for completing the verification before the contract is upgraded. Due to the tamper-proof property of the blockchain, the intelligent contracts cannot be changed after being linked, so that in the prior art (including a traditional contract model and a three-layer contract model), a large amount of tests are performed before the contracts are linked to ensure the correctness and the safety of the contracts. However, contract detection performed under the chain can only prevent known vulnerabilities, and cannot detect unknown vulnerabilities, i.e., cannot detect vulnerabilities on the chain. Therefore, the chain upgrading method provided by the embodiment of the invention enhances the security of upgrading on the intelligent contract chain by using the verification layer contract in the four-layer intelligent contract.

For example, for a four-tier intelligent contract, the N validation tier contracts may include one or more of the following contracts:

the method comprises the steps of detecting contracts of contract integrity, detecting contracts of contract boundary values, detecting contracts of abnormal flows in the contracts, detecting contracts of contract key points and verifying contracts of upgrading related information.

For example, for a financial contract, it may be detected whether information, a transaction mode, a transaction amount, and the like of both parties of the transaction are complete. Detecting a contract boundary value is to detect whether the data in the contract exceeds the boundary value, for example, for the date of birth, it can be detected whether it is a future date. The detection of abnormal flows in contracts is particularly important for financial contracts, because abnormal attacks often exist in metal contracts, and when the abnormal flows are detected to include attack operations in the flows, the abnormal flows in the contracts can be determined. The method for detecting the contract key points is to detect whether the key contract content specified in advance in the contract is normal, for example, when the intelligent contract is a contract which needs the prerequisite to be satisfied to be effective, whether the prerequisite is satisfied is a contract key point. The upgrade-related information is one or more of information related to the contract upgrade that is not included in the contract essence, such as whether the upgrade time is expired, whether the user initiating the upgrade request is legitimate, and the like.

It can be understood that, on the basis of the four-layer architecture provided in the embodiment of the present invention, a contract enactment party may implement any logic that is desired to be verified in a verification-layer contract, and may arrange the logic that is desired to be verified in different verification-layer contracts according to differences of verification objects, verification contents, verification means, and the like, so as to be flexibly invoked in the following process, thereby implementing flexible verification.

On the basis of the four-layer intelligent contract model, the chain upgrading method of the four-layer intelligent contract provided by the embodiment of the invention comprises the following steps:

s10: deploying a new version of a target contract to be updated to the blockchain; wherein the target contract is a business layer contract or a storage layer contract in the four-layer intelligent contract.

Here, a specific implementation manner of deploying the new version of the target contract to the blockchain is the same as a manner of adding data to the blockchain in the prior art, and details are not repeated in the embodiment of the present invention.

S20: receiving a contract upgrading request; the contract upgrading request carries a new version address and an old version address of a target contract, and also carries agent parameters and verification parameters related to the upgrading.

The verification parameters are used for specifying J e [1, J ] verification layer contracts required for verifying the new version of the target contract; the agent parameters are used to specify the I e 1, I agent-level contracts needed to upgrade the target contract.

In practical application, a user can initiate a request through a node of a block chain; after receiving the request sent by the user, the node judges whether the request is a contract upgrading request or a common request according to the request parameters, and if the judgment result is the contract upgrading request, the node continues to execute step S30. The request parameter may be a status parameter for characterizing whether the request sent by the user is a contract upgrade request or a normal request, and for example, 1 may be used to represent the contract upgrade request, and 0 may be used to represent the normal request. Alternatively, in another implementation, if the request received by the node includes the above-mentioned verification parameter, the request may be determined to be a contract upgrade request according to the verification parameter.

S30: a new version at the new version address is verified by invoking a first one of the I e [1, I ] proxy layer contracts and invoking a first one of the J e [1, J ] verification layer contracts.

It will be appreciated that the first proxy-layer contract is a contract for invoking a first validation-layer contract. And the node calls a first verification layer contract on the block chain through the first agent layer contract to realize the verification of the new version. This step involves an operation that calls on the data on the blockchain, so that the operation can be automatically recorded uplink.

S40: and updating the old version address of the target contract into the new version address by I belongs to [1, I ] second proxy layer contracts in the proxy layer contracts, and destroying the old version at the old version address.

Here, the second proxy layer contract includes: contracts that perform modify operations on old version addresses of target contracts recorded on blockchains, and contracts that perform delete operations on old versions recorded on blockchains. This step involves modifying and deleting data on the blockchain, not tampering with the blockchain, because each operation is automatically recorded and linked up, so-called modify/delete, which means that the operation result of the distributed ledger is changed before and after modification/before and after deletion.

It is understood that the step S40 is completed, and the target contract is upgraded. In addition, if the target contract is about a storage tier contract, the chain upgrading method provided by the embodiment of the present invention may further include:

updating the address of a storage layer contract corresponding to a related service layer contract through a third proxy layer contract in I epsilon [1, I ] proxy layer contracts; wherein the associated business tier is approximately: and carrying out contracts of data structure definition and data storage by using the target contract.

Therefore, the address of the storage contract of the service layer contract related to the target contract is correspondingly updated, so that the whole four-layer intelligent contract is upgraded at a low cost.

In the chain upgrading method of the four-layer intelligent contract, the intelligent contract is designed into a four-layer structure of a proxy layer, a service layer, a storage layer and a verification layer according to the idea of attention point separation, and each layer of contract can be designed into a plurality of sub-contracts. Therefore, the contracts in each layer and the same layer are independent, componentization is realized, the influence on other contracts caused by redeployment of a single contract is reduced, and the engineering requirements of the intelligent contracts are well adapted. Compared with a data layer contract in the existing three-layer contract model, the storage layer contract is developed based on the precompiled contract and oriented to the base table, so that the relation between the storage layer contract and the service layer contract is decoupled, the visibility of the storage layer contract is weakened, the local complexity and the data migration cost of the contract are reduced, and the low-cost chain upgrading and the contract version compatibility of the storage contract can be realized.

In addition, in the embodiment of the invention, before the intelligent contract is upgraded, the multi-angle verification can be carried out on the new version by calling the verification layer contract, so that the chain loophole is effectively detected, and the upgrading safety of the intelligent contract is enhanced.

It can be understood that there is a certain difference between the intelligent contract and a general computer program, and particularly, the intelligent contract must have security and stability, otherwise, the stable operation of the intelligent contract in the block chain cannot be guaranteed. Therefore, the method for realizing the on-chain upgrading of the intelligent contract by adopting the on-chain verification in the embodiment of the invention can effectively ensure the safety and the stability of the intelligent contract.

In practical application, the requirements for upgrading the intelligent contracts include various requirements; illustratively, table 1 shows four of these classical requirements; among them, demand 1 is not uncommon, and demands 2, 3, and 4 are more common.

TABLE 1

Demand agent layer contract validation layer contract service layer contract storage layer contracts

1 upgrade continue use

2 continuing to use the second use stage

3 continuing to use and upgrade to continue to use

4 follow-up upgrade

In the embodiment of the invention, the four-layer intelligent contracts comprise I agent layer contracts, M service layer contracts, N storage layer contracts and J verification layer contracts; by utilizing the chain upgrading method provided by the embodiment of the invention, any one of M service layer contracts, N storage layer contracts and J verification layer contracts can be upgraded on a chain. When a plurality of contracts in the J + M + N contracts need to be upgraded, the plurality of contracts to be upgraded can be sequentially upgraded by using the method provided by the embodiment of the invention according to the sequence of upgrading the storage layer, upgrading the service layer and upgrading the verification layer.

In addition, if a certain proxy contract in the I proxy layer contracts needs to be upgraded, only the new version of the proxy contract needs to be deployed, and the addresses of other contracts to be called by the proxy contract need to be configured in the new version of the proxy contract. It should be noted that, the upgrading of the proxy contract may cause the change of the user call interface, and the call interface on the user side needs to be changed accordingly.

Optionally, in an implementation, the mode of performing chain verification on the four-layer intelligent contract by the verification layer contract includes:

Specifically, a mode of assertion rollback and last rollback is adopted to perform on-chain verification on a target contract to be upgraded in a four-layer intelligent contract.

Here, the purpose of using assertion rollback and last line rollback is to guarantee that data does not fall off the disk, i.e., to guarantee that data generated by the verification process is not additionally stored on the chain, in consideration of the purity of data on the chain.

It is understood that the assertion means that if the operation result obtained after the verification layer contract is called matches the expected value, the assertion succeeds, and if the operation result does not match, the assertion fails. The rollback is to fail all previous operations, i.e. to return all states to the original state. Thus, asserting rollback refers to: after an assertion fails, all operations performed prior to this assertion are restored to the initial state.

For example, assume in a verification layer contract that initial state i =0, the first line of code: let i =1,; the second line of code: i = 3; the third line of codes: an assertion rollback with i still equal to 0 if the assertion fails and i =3 if the assertion succeeds and the next fourth row of code is executed.

The last rollback means that a code of a rollback operation is placed on a code of the last line of the verification layer contract, and all previous operations are necessarily disabled as long as the contract flow can go to the last line. The purpose of this is: the assertion before the contract flow can go to the last line for description is totally successful, namely, the assertion is totally successful, and after the assertion is rolled back, the data generated in the contract execution process does not need to be stored in a chain.

By asserting rollback and ending rollback, it is meant that both of the above rollback modes are employed in the verification layer contract.

In one embodiment, a single proxy-layer contract can provide user-oriented invocation links for the following contracts:

one or more business-level contracts, or, alternatively, one or more verification-level contracts.

Briefly, in embodiments of the present invention, proxy-layer contracts and business-layer contracts may be in a one-to-one or one-to-many relationship; the proxy layer contract may be in a one-to-one or one-to-many relationship with the validation layer contract as well.

In contrast, in the existing three-tier contract model, interface contracts and business contracts are in a one-to-one relationship, and one interface contract can only be linked to only one business contract version, usually to the latest version of the business contract, at the same time. In addition, in the existing three-layer contract model, the interface contract and the data contract are in a one-to-one relationship, and both the entrance contract and the data contract are kept unchanged in the process of service contract version iteration.

In the embodiment of the invention, a single proxy layer contract can link one or more layer service contracts to make contract calls, or is more flexible, and only the proxy layer contract is visible for users, and the service layer contracts are invisible for users. In addition, a single agent layer contract may also link one or more verification layer contracts to verify a target contract, that is, the agent layer contract may select a part of the verification contracts to selectively verify the target contract, or may select all the verification layer contracts to perform unified, streamlined and standardized verification on the target contract.

In one embodiment, a single verification-layer contract is capable of verifying:

one or more service-level contracts or, alternatively, one or more storage-level contracts.

Briefly, in embodiments of the present invention, a validation layer contract may be in a one-to-one or one-to-many relationship with a business layer contract; the verification tier contract may likewise be in a one-to-one or one-to-many relationship with the storage tier contract.

Thus, a single verification-layer contract may be designed in a universal manner of verification, enabling verification of more than one business-layer contract, or of more than one storage-layer contract.

In one embodiment, a single storage tier contract enables data structure definition and data storage of data of one or more business tier contracts; moreover, data of a single business layer contract can be defined in a data structure and stored by one or more storage layer contracts.

That is, the storage tier contract and the business tier contract may be in a one-to-one relationship, a many-to-one relationship, a one-to-many relationship, or a many-to-many relationship.

In contrast, in the existing three-layer contract model, the service contract and the data contract are in a many-to-one relationship, because in order to realize the reusability of the data contract, the service contracts of different versions inherit the same data contract, the corresponding service logic data is stored in the same data contract, and the updating of the storage contract is difficult to realize.

Based on the above three embodiments, in a preferred embodiment, the proxy layer contract and the business layer contract may be in a one-to-many relationship; the agent layer contract and the verification layer contract can be in one-to-many relationship as well; the storage tier contract and the business tier contract may be in a many-to-many relationship.

Thus, the four-tier smart contract may be represented as:

Z={SC,R},

SC={P,T,L,D}；

wherein P represents a set of agent layer contracts in a four layer intelligent contract; t represents a set of verification layer contracts in a four-layer intelligent contract; l represents a set of business layer contracts in a four-layer intelligent contract; d represents a set of storage layer contracts in the four-layer intelligent contract; and R represents the corresponding relation between contracts in the four-layer intelligent contract.

In an optional implementation manner, after the step S40 is completed, that is, after the old version address of the target contract is updated to the new version address, and the old version at the old version address is destroyed, the chain upgrading method provided in the embodiment of the present invention may further include: and storing the updated process information on the chain to the block chain.

Here, the procedure information of the chain upgrade may include: contract type, old version address, new version address, user id, contract upgrading description and upgrading time of the target contract; of course, it is not limited thereto.

In an optional implementation manner, the chain upgrading method provided by the embodiment of the present invention may further include the following steps:

the identity of the user initiating the contract upgrade request is verified to continue executing the chain upgrade method when the verification passes.

Therefore, illegal upgrade of the four-layer intelligent contract can be effectively avoided.

In a specific embodiment, referring to fig. 3, after a user sends a request, a node first determines whether the request is a contract upgrading request; if the request is a common request, user identity authentication is carried out, and the user can be upgraded only if the user has corresponding authority; and executing the business logic after the verification is passed. If the contract is the contract upgrading request, further judging whether the contract is the upgrading request of the storage layer; if the storage layer contract is the upgrading request of the storage layer contract, firstly verifying the storage layer contract, updating the storage layer contract after the verification is passed, correspondingly updating the address of the storage contract layer contract corresponding to the relevant service layer contract after the updating, and then performing version management operation; the version management operation described here is to store the process information upgraded in the current chain into the blockchain. If the contract is the upgrading request of the business layer contract, firstly verifying the business layer contract, updating the business layer contract after the verification is passed, and then performing version management operation.

In addition, in practical application, the process of implementing the deployment and upgrade of the four-layer intelligent contract may be as follows:

(one) contract logic defines: and defining the integral logic of the intelligent contract, such as a service function, a data structure, a storage mode and the like.

(II) contract hierarchical design: designing and coding the whole intelligent contract according to the architecture of an agent layer, a verification layer, a service layer and a storage layer;

(III) contract deployment: respectively carrying out chain deployment on each layer of contracts, calling corresponding configuration functions of the contracts to carry out contract configuration according to the hierarchical relation after successful deployment, and realizing establishment of the corresponding relation between the contracts;

(IV) contract upgrading: when the business of the contract needs to be expanded or the contract has a bug, the intelligent contract of the corresponding level is only needed to be modified and redeployed, and the low-cost upgrade, verification and version compatibility of the contract on the chain can be realized by reconfiguration (updating the corresponding relation between the contracts) after verification.

It should be noted that the terms "first" and "second" are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more features. In the description of the present invention, "a plurality" means two or more unless specifically defined otherwise.

In the description of the specification, reference to the description of the term "one embodiment", "some embodiments", "an example", "a specific example", or "some examples", etc., means that a particular feature or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the invention. In this specification, the schematic representations of the terms used above are not necessarily intended to refer to the same embodiment or example. Furthermore, the particular features or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, various embodiments or examples described in this specification can be combined and combined by those skilled in the art.

While the present application has been described in connection with various embodiments thereof, other variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed application, from a review of the drawings, the disclosure, and the appended claims.

The foregoing is a more detailed description of the present invention in connection with specific preferred embodiments, and it is not to be construed that the specific embodiments of the present invention are limited to those descriptions. It will be apparent to those skilled in the art that various modifications, additions and substitutions can be made without departing from the spirit of the invention.

Claims

1. A method for chain upgradmg of a four-tier intelligent contract, the four-tier intelligent contract comprising: i proxy layer contracts, M service layer contracts, N storage layer contracts and J verification layer contracts, wherein I is more than or equal to 1, J is more than or equal to 1, M is more than or equal to 1, and N is more than or equal to 1; the agent layer contract is used for providing a user-oriented calling link for the four-layer intelligent contract; the business layer contract is used for realizing business logic of the four-layer intelligent contract; the storage layer contract is used for realizing data structure definition and data storage in the business layer contract, and the storage layer contract is a contract which is developed based on a precompiled contract and faces a base table; the verification layer contract is used for performing on-chain verification on the four-layer intelligent contract;

the chain upgrading method comprises the following steps:

2. The chain upgrade method as claimed in claim 1, wherein when the target contract is about a storage tier contract, the chain upgrade method further comprises:

3. The method of chain upgrading of claim 1, wherein the verifying a layer contract in a manner that verifies the four-layer intelligent contract on a chain comprises:

4. A method of chain upgrade according to claim 1, in which a single proxy layer contract is capable of providing user-oriented call links to contracts:

5. A chain upgrade method according to claim 1 wherein a single verification layer contract is capable of verifying the following contracts:

6. Chain upgrading method according to claim 1,

the single storage layer contract can carry out data structure definition and data storage on the data of one or more business layer contracts;

7. The chain upgrading method of claim 1, wherein the precompilation contract is a precompilation contract in a FISCO BCOS.

8. The chain upgrading method of claim 1, further comprising:

9. The chain upgrading method of claim 1, further comprising:

10. The chain upgrading method of claim 1, wherein the N validation layer contracts include one or more of the following contracts:

wherein the contract key is pre-specified key contract content.