HK40055340B - Method and apparatus for deploying blockchain contract, device and storage medium - Google Patents

Description

Blockchain contract deployment method, device, equipment and storage medium

This application is a divisional application of the Chinese patent application filed with the China Patent Office on November 27, 2019, with application number 201911180240.3 and application name “Blockchain Contract Deployment Method, Device, Equipment and Storage Medium”, all contents of which are incorporated by reference into this application.

Technical Field

The present application relates to the field of Internet technology, and in particular to a blockchain contract deployment method, apparatus, device, and storage medium.

Background Art

A smart contract is a computer protocol designed to communicate, verify, or execute contracts in an information-based manner. It allows for trusted, traceable, and irreversible transactions without a third party. Smart contracts, as programs on a blockchain, can be created and deployed by their creators. Of course, deploying updatable smart contracts on a blockchain can be achieved through the use of proxy contracts.

In the existing technology, a proxy contract (i.e., a piece of program code) can be created for a business and deployed to the blockchain. However, when there are multiple businesses, a proxy contract needs to be written for each business in turn, which involves a large amount of code and leads to low efficiency in the development of proxy contracts.

Summary of the Invention

The embodiments of the present application provide a blockchain contract deployment method, apparatus, device, and storage medium, which can improve the development efficiency of contracts in the blockchain.

The present invention provides a blockchain contract deployment method, including:

Receive the contract registration request sent by the requesting node, obtain the contract name, the first address corresponding to the data contract, and the second address corresponding to the business contract carried in the contract registration request; the data contract is used to store business data, and the business contract is used to store business logic;

Obtain a contract template from the contract management platform, bind the first address and the second address based on the contract template, obtain a proxy contract associated with the business contract and the data contract, and generate a third address corresponding to the proxy contract;

Generate mapping relationship information between the third address and the contract name, and store the mapping relationship information in the contract management platform.

An embodiment of the present application provides a blockchain contract deployment device, including:

The receiving module is used to receive the contract registration request sent by the requesting node and obtain the contract name, the first address corresponding to the data contract, and the second address corresponding to the business contract carried in the contract registration request; the data contract is used to store business data, and the business contract is used to store business logic;

Create a module for obtaining a contract template from the contract management platform, binding the first address and the second address based on the contract template, obtaining a proxy contract associated with the business contract and the data contract, and generating a third address corresponding to the proxy contract;

The storage module is used to generate mapping relationship information between the third address and the contract name, and store the mapping relationship information in the contract management platform.

The device further comprises:

The block generation module is used to obtain the data contract and business contract uploaded by the requesting node and generate the contract block based on the data contract and business contract;

The consensus module is used to determine the data contract and business contract as being released successfully when the contract block is passed by consensus in the blockchain network;

The address determination module is used to determine the first address corresponding to the data contract in the successful release state and the second address corresponding to the business contract in the successful release state according to the account information corresponding to the requesting node, and send the first address and the second address to the requesting node.

The building blocks include:

A parameter input unit, configured to obtain a contract template from the contract management platform and input the first address and the second address as parameters into the contract template;

An interface calling unit, configured to call an address setting interface from a business contract corresponding to the second address based on the contract template;

The binding unit is used to input the first address into the business contract according to the address setting interface, bind the business contract and the data contract, and obtain the proxy contract.

The device further comprises:

The traversal module is used to traverse the historical mapping relationship information stored in the contract management platform based on the contract name;

The verification module is used to return a name change prompt to the requesting node if the contract name exists in the historical mapping relationship information;

The verification module is further used to generate mapping relationship information between the third address and the contract name if the contract name does not exist in the historical mapping relationship information, and store the mapping relationship information in the contract management platform.

The device further comprises:

The query request receiving module is used to obtain the contract name carried in the contract query request when receiving the contract query request sent by the requesting node;

The address query module is used to obtain a third address that has a mapping relationship with the contract name from the contract management platform, and return the third address to the requesting node so that the requesting node stores the third address and the contract name locally.

The contract management platform includes an association relationship between a third address and a plurality of nodes, wherein the plurality of nodes include a management node and an authorized access node corresponding to the proxy contract;

The device also includes:

The query request receiving module is used to obtain the contract name carried in the contract query request when receiving the contract query request sent by the requesting node;

An associated node acquisition module, configured to obtain a third address having a mapping relationship with the contract name from the contract management platform, and obtain multiple nodes associated with the third address;

a query authority determination module, configured to, if a requesting node exists among the plurality of nodes, determine that the requesting node has query authority, and return the third address to the requesting node, so that the requesting node stores the third address and the contract name locally;

The query authority determination module is also used to determine that the requesting node does not have the query authority if the requesting node does not exist among the multiple nodes, and return authority prompt information to the requesting node.

The device further comprises:

The transaction data acquisition module is used to obtain the transaction data uploaded by the requesting node and obtain the proxy contract based on the third address carried in the transaction data;

The data operation module is used to call the business contract according to the proxy contract, and based on the business logic in the business contract, operate the data contract and transaction data to generate the contract processing results corresponding to the transaction data.

The device further comprises:

An update request acquisition module, configured to obtain an update request for the proxy contract, and obtain the first address and the fourth address corresponding to the updated business contract based on the update request;

A test contract generation module, configured to input the fourth address and the first address as parameters into a contract template to generate a test proxy contract;

The contract update module is used to update the proxy contract based on the test proxy contract that passed the test when the test proxy contract passes the test.

Among them, the contract update module includes:

An address updating unit, configured to freeze the proxy contract when the test proxy contract passes the test, and update the second address in the proxy contract to the fourth address in the test proxy contract in the test passed state;

The updated contract determining unit is configured to determine the proxy contract including the first address and the fourth address as an updated proxy contract; the updated proxy contract is associated with the third address.

In one aspect, an embodiment of the present application provides a node device, including a memory and a processor. The memory stores a computer program. When the computer program is executed by the processor, the processor executes the steps of the method in one aspect of the embodiment of the present application.

On one hand, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. The computer program includes program instructions. When the program instructions are executed by a processor, the steps of the method in one aspect of the embodiment of the present application are executed.

In an embodiment of the present application, upon receiving a contract registration request from a requesting node, a blockchain node can obtain the contract name, the first address corresponding to the data contract, and the second address corresponding to the business contract carried in the contract registration request, obtain a contract template from the contract management platform, bind the first address and the second address based on the contract template, obtain a proxy contract associated with the data contract and the business contract, generate a third address corresponding to the proxy contract, and store the mapping relationship information between the third address and the contract name in the contract management platform. Thus, by creating a contract management platform in the blockchain and writing a contract template in the contract management platform, the business contract address and the data contract address can be input as parameters into the contract template to bind the data contract and the business contract, completing the deployment process of the proxy contract in the blockchain. The use of contract templates can reduce the development process of proxy contracts, thereby improving the efficiency of contract development in the blockchain.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

FIG1 is a diagram of a network architecture provided by an embodiment of the present application;

FIG2 is a schematic diagram of a blockchain contract deployment scenario provided by an embodiment of the present application;

FIG3 is a flow chart of a blockchain contract deployment method provided in an embodiment of the present application;

FIG4 is a schematic diagram of a smart contract execution scenario provided by an embodiment of the present application;

FIG5 is a flow chart of another blockchain contract deployment method provided in an embodiment of the present application;

FIG6 is a schematic diagram of a contract upgrade scenario provided by an embodiment of the present application;

FIG7 is a schematic diagram of the structure of a blockchain contract deployment device provided in an embodiment of the present application;

FIG8 is a schematic structural diagram of a node device provided in an embodiment of the present application.

DETAILED DESCRIPTION

The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

Blockchain is a new application model for computer technologies, including distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Essentially, a blockchain is a decentralized database, a series of data blocks linked using cryptographic methods. Each block contains information about a batch of online transactions, used to verify the validity of this information (to prevent counterfeiting) and generate the next block. Blockchain can include the underlying blockchain platform, the platform product and service layer, and the application service layer.

The underlying blockchain platform can include processing modules such as user management, basic services, smart contracts, and operation monitoring. Among them, the user management module is responsible for the identity information management of all blockchain participants, including maintaining public and private key generation (account management), key management, and maintaining the corresponding relationship between the user's real identity and the blockchain address (authority management), etc., and under authorization, it supervises and audits the transactions of certain real identities and provides risk control rule configuration (risk control audit); the basic service module is deployed on all blockchain node devices to verify the validity of business requests, and records the valid requests to the storage after consensus is reached. For a new business request, the basic service first adapts the interface to parse and authenticate the request (interface adaptation), and then encrypts the business information through the consensus algorithm (consensus management). The smart contract module is responsible for the registration, issuance, triggering and execution of contracts. Developers can define the contract logic in a programming language and publish it to the blockchain (contract registration). According to the logic of the contract terms, the contract logic is triggered by calling keys or other events to trigger execution. The contract logic is completed, and the contract upgrade and cancellation functions are also provided. The operation monitoring module is mainly responsible for the deployment, configuration modification, contract setting, cloud adaptation and real-time status visualization output of the product during the product release process, such as alarms, network status monitoring, and node device health monitoring.

Smart contracts can be understood as computer programs that run on a distributed ledger (i.e., blockchain) with pre-set rules, state, and conditional responses. They can encapsulate, verify, and execute complex behaviors of distributed nodes to facilitate information exchange, value transfer, and asset management. Based on blockchain's distributed architecture and consensus algorithms, smart contracts allow mutually untrusting users to complete transactions without the need for any trusted third-party intermediary or authority. Furthermore, digital smart contracts can be flexibly embedded in various tangible or intangible assets, transactions, and data, enabling active or passive asset and information management and control, and gradually building programmable intelligent assets and systems.

Please refer to Figure 1, which is a network architecture diagram provided by an embodiment of the present application. As shown in Figure 1, the network architecture may include multiple node servers (as shown in Figure 1, specifically including node server 10a, node server 10b, node server 10c and node server 10d) and a request terminal 10e. Among them, node server 10a, node server 10b, node server 10c and node server 10d are all represented as blockchain nodes in the blockchain network, and the request terminal 10e may refer to a user terminal. The request terminal 10e can upload data that needs to be on the chain (such as newly generated transaction data, written smart contracts, etc.) to the blockchain network, and request the blockchain network to upload the uploaded data to the chain. After the request terminal 10e uploads data to the blockchain network, any blockchain node in the blockchain network (such as node server 10a) can generate a new block based on the data uploaded by the request terminal 10e, and broadcast the newly generated block in the blockchain network so that the nodes in the blockchain network can reach a consensus on the newly generated block, that is, after the node server 10a generates a new block, it can broadcast the newly generated block to node server 10b, node server 10c and node server 10d. The data passed by consensus can be formally uploaded to the chain, and the nodes in the blockchain network can store the blockchain locally. A contract management platform (i.e., a computer program that can implement contract management functions) can be created in the nodes in the blockchain network. The contract management platform has functions such as smart contract registration, agency, and upgrade. The smart contract in the embodiment of the present application is a business processing contract jointly participated in by the contract request terminal and the blockchain node. Each blockchain node can trigger and execute the smart contract, that is, it can provide an operating environment (Ethereum virtual machine) for the smart contract.

The requesting terminal 10e may include a mobile phone, a tablet computer, a laptop computer, a PDA, a mobile internet device (MID), a wearable device (such as a smart watch, a smart bracelet, etc.), etc.

Please refer to Figure 2, which is a schematic diagram of a blockchain contract deployment scenario provided by an embodiment of the present application. Due to the immutability of the blockchain, the source code of the smart contract cannot be modified after it is deployed in the blockchain. If the business requirements change, the smart contract needs to be redeployed, and the original data will be lost. Therefore, an upgradeable smart contract is proposed. The principle of the upgradeable smart contract is to separate the data contract from the data contract, and use the business contract to call the data contract. When the business requirements change, the business contract can be redeployed, and the data stored in the data contract will not be lost. The data contract is used to store business data, and the business contract is used to maintain business logic. In the embodiment of the present application, the business contract and the data contract can be separated by means of a proxy contract. The essence of the proxy contract is to achieve the purpose of upgrading the main processing logic by newly deploying a contract.

As shown in Figure 2, the proxy contract deployment process is described using a requesting terminal 10e and the node server 10a of the embodiment corresponding to Figure 1 as examples. Requesting terminal 10e can submit the developer's data contract and business contract to the blockchain network along with the initiated transaction. Upon receiving the transaction containing the data contract and business contract submitted by requesting terminal 10e, node server 10a in the blockchain network can verify the signature of the received transaction containing the data contract and business contract. The purpose of the signature verification is to detect whether the transaction containing the data contract and business contract has been tampered with during transmission. If the signature verification fails, it indicates that requesting terminal 10e may have been tampered with during the transaction upload process, and the transaction containing the data contract and business contract can be deleted. If the signature verification passes, it indicates that the transaction actually received by node server 10a is the same as the transaction submitted by requesting terminal 10e, that is, the transaction containing the data contract and business contract has not been tampered with during transmission.

Node server 10a can package the signed transactions carrying data contracts and business contracts into block 20a. The block header of block 20a contains the hash corresponding to the block with the highest block height in the blockchain. The block body of block 20a can be used to store the business contract and data contract. Node server 10a can broadcast the newly generated block 20a in the blockchain network, that is, send block 20a to each node in the blockchain network (here, it is assumed that all nodes in the blockchain network are consensus nodes) so that each node in the blockchain network can perform consensus verification on block 20a. Once block 20a passes consensus (such as more than 51% of the nodes in the blockchain network pass the consensus verification of block 20a), block 20a can be added to the blockchain for formal on-chain, indicating that the data contract and business contract have been successfully created in the blockchain.

After the data contract and business contract are successfully created, the Ethereum virtual machine 20b (EVM) in the node server 10a can generate contract addresses based on the account information of the requesting terminal 10e, namely, address 1 corresponding to the data contract and address 2 corresponding to the business contract. Address 1 is used to indicate the data contract and can be understood as the identification information corresponding to the data contract. Address 2 is used to indicate the business contract and can be understood as the identification information corresponding to the business contract. Different contracts correspond to different addresses. Node server 10a can return the generated address 1 and address 2 to the requesting terminal 10e.

After receiving address 1 and address 2 returned by node server 10a, request terminal 10e can send a contract registration request to the blockchain and send the contract name, address 1, and address 2 to node server 10a. After receiving the contract registration request from request terminal 10e, node server 10a can obtain contract template 20d from contract management platform 20c and input address 1 and address 2 as parameters into contract template 20d. Since the business contract contains an interface for setting the data contract address, the contract template 20d with address 1 and address 2 input can call the set method in the data contract address interface to pass address 1 into the business contract, completing the binding of the business contract and the data contract. At this time, the data contract and the proxy contract 20e associated with the data contract can be obtained.

The node server 10a can also generate a proxy contract address corresponding to the proxy contract 20e based on the account information of the requesting terminal 10e, and bind the proxy name and the proxy contract address, generate mapping relationship information between the contract name and the proxy contract address, and store the mapping relationship information between the contract name and the proxy contract address in the contract management platform, such as there is a mapping relationship between the proxy contract address 1 and the contract name 1, there is a mapping relationship between the proxy contract address 2 and the contract name 2, and so on.

It should be noted that the data contract, business contract, and proxy contract 20e are all computer program codes. Developers can use a high-level smart contract language to write them. A compiler can compile the contracts written in the high-level language into bytecode for the Ethereum virtual machine of a blockchain node (such as node server 10a). The Ethereum virtual machine can be used to interpret and execute the bytecode in the smart contract. High-level smart contract languages include, but are not limited to, Solidity (a smart contract programming language), Serpent (a smart contract programming language), and LLL (a smart contract programming language). For example, developers can use Solidity to write data contracts and business contracts, and use a compiler to compile the data contracts and business contracts written in Solidity into Ethereum virtual machine bytecode, respectively. The compiled Ethereum virtual machine bytecode is then submitted to the blockchain network along with the transaction initiated by the requesting terminal 10e for on-chain storage.

Please refer to Figure 3, which is a flowchart of a blockchain contract deployment method provided in an embodiment of the present application. It is understood that the method can be executed by a computer device, which can be a node server in a blockchain network or other node device in a blockchain network. As shown in Figure 3, the method may include the following steps:

Step S101: Receive a contract registration request from a requesting node and obtain the contract name, the first address corresponding to the data contract, and the second address corresponding to the business contract carried in the contract registration request; the data contract is used to store business data, and the business contract is used to store business logic;

Specifically, the requesting node (such as the requesting terminal 10e in the embodiment corresponding to FIG2 above) can send a contract registration request to the blockchain network, that is, apply to the blockchain network to generate a proxy contract and upload the contract name, the first address corresponding to the data contract, and the second address corresponding to the business contract to the blockchain network. After receiving the contract registration request sent by the requesting node, the node server in the blockchain network (such as the node server 10a in the embodiment corresponding to FIG2 above) can obtain the contract name, first address, and second address uploaded by the requesting node. Among them, the data contract is used to store business data (variables, structures, and mappings, etc.); the business contract is used to maintain business logic. The business contract contains an interface for setting the data contract address. Therefore, the business contract can call the data contract, and based on the business logic in the business contract, the business data stored in the data contract can be operated.

Before sending a contract registration request to the blockchain network, the requesting node must also upload the data contract and business contract written by the developer to the blockchain network for on-chain processing, in order to obtain the first address corresponding to the data contract and the second address corresponding to the business contract. When the data contract and business contract are submitted to the blockchain network along with the transaction initiated by the requesting node, the node server in the blockchain network can obtain the data contract and business contract submitted by the requesting node and generate a contract block based on the data contract and business contract. When the contract block is passed by consensus in the blockchain network, the data contract and business contract are determined to be in a successfully published state. Based on the account information corresponding to the requesting node, the first address corresponding to the data contract in the successfully published state and the second address corresponding to the business contract in the successfully published state are determined, and the first and second addresses are sent to the requesting node. In other words, data contracts and business contracts are written by developers, and after being agreed upon and signed by multiple parties, they can be submitted to the blockchain network along with the transaction initiated by the requesting node. The node server in the blockchain network can package the transactions carrying data contracts and business contracts into contract blocks, and based on the point-to-point transmission method in the blockchain, the contract blocks are transmitted over the network so that the remaining nodes in the blockchain network can perform consensus verification on the contract blocks. After the consensus is passed, the contract blocks can be officially uploaded to the chain. The passing of the contract block consensus indicates that the data contract and business contract have been successfully released, and the data contract and business contract can be stored in the blocks of the blockchain. The node server can determine the addresses corresponding to the data contract and the business contract based on the account information of the requesting node, that is, determine the first address corresponding to the data contract and the second address corresponding to the business contract. Then, the node server can return the first address corresponding to the data contract and the second address corresponding to the business contract to the requesting node, so that the requesting node can apply to generate a proxy contract based on the first address and the second address.

Step S102: Obtain a contract template from the contract management platform, bind the first address and the second address based on the contract template, obtain a proxy contract associated with the business contract and the data contract, and generate a third address corresponding to the proxy contract;

Specifically, the node server can obtain a contract template from the contract management platform, input the first address corresponding to the data contract and the second address corresponding to the business contract as parameters into the contract template, call the address setting interface from the business contract corresponding to the second address through the contract template with the input parameters, input the first address into the business contract according to the address setting interface, bind the business contract and the data contract, and obtain a proxy contract for the above-mentioned data contract and business contract. Among them, each node server in the blockchain network can pre-create a contract management platform (this contract management platform can also be understood as a smart contract), and a proxy contract code (i.e., a contract template) can be stored in the contract management platform for efficient generation of new proxy contracts. The contract template can be understood as a proxy contract framework. When the data contract address and the business contract address are input as parameters into the contract template, a new proxy contract can be quickly created. The proxy contract has functions such as agency, management, and update. The address setting interface may include a method for setting the data contract address. By storing the data contract address in the method for setting the data contract address, the address contract and the business contract can be bound. For example, if the address corresponding to the data contract is: address 1, by calling the method for setting the data contract address (such as the setDataContractAddr() method) and passing address 1 into the business contract, the binding between the data contract and the business contract can be achieved.

Among them, generating a proxy contract first requires creating a data contract. The data contract can provide a data storage structure for subsequent contracts to inherit this structure; creating a business contract. The business contract can be used to maintain business logic, and the business contract can inherit the data storage structure in the data contract; the proxy contract can be generated according to the contract template. The proxy contract can inherit the data storage structure in the data contract. A business contract address variable can be defined in the proxy contract, and a method for replacing the business contract address can be provided. In the embodiment of the present application, after the first address corresponding to the data contract and the second address corresponding to the business contract are input into the contract template as parameters, the method for setting the business contract address in the contract template is called to store the second address of the business contract, and the method for setting the data contract address in the business contract is called to pass the first address into the business contract. At this time, a proxy contract for the above-mentioned data contract and the above-mentioned business contract can be obtained. For example, the address corresponding to Data Contract 1 is: Address 1, and the address corresponding to Business Contract 2 is: Address 2. After entering Address 1 and Address 2 as parameters into the contract template, you can call the method for setting the data contract address in Business Contract 2 and pass Address 1 into Business Contract 2 to complete the binding between Data Contract 1 and Business Contract 2. That is, the proxy contract 1 generated at this time is a proxy contract for Data Contract 1 and Business Contract 2. If Address 1 and Address 3 corresponding to Business Contract 3 are entered as parameters into the contract template, you can call the method for setting the data contract address in Business Contract 3 and pass Address 1 into Business Contract 3 to complete the binding between Data Contract 1 and Business Contract 3. That is, the proxy contract 2 generated at this time is a proxy contract for Data Contract 1 and Business Contract 3.

After obtaining the proxy contract associated with the data contract and business contract locally on the node server, the proxy contract can be packaged into blocks. After being transmitted through the peer-to-peer network and verified by the blockchain node, the block used to store the proxy contract will be officially uploaded to the chain. Then, based on the account information of the requesting node, the Ethereum virtual machine in the node server can determine the proxy contract address corresponding to the geographic contract, which can also be called the third address.

Step S103: Generate mapping relationship information between the third address and the contract name, and store the mapping relationship information in the contract management platform.

Specifically, the node server may bind the contract name carried in the contract registration request to the third address corresponding to the proxy contract, generate mapping relationship information between the third address and the contract name, and store the generated mapping relationship information in the contract management platform. It should be understood that each time a new proxy contract is generated, the mapping relationship information between the address of the new proxy contract and the proxy contract name may be stored in the contract management platform. In other words, the contract management platform may store multiple mapping relationship information, each mapping relationship information including a binding relationship between a proxy contract and a contract name.

Among them, after obtaining the contract name carried in the contract registration request, the node server can traverse the historical mapping relationship information stored in the contract management platform based on the contract name; if the contract name exists in the historical mapping relationship information, a name change prompt information is returned to the requesting node; if the contract name does not exist in the historical mapping relationship information, after generating the proxy contract, the mapping relationship information between the third address corresponding to the proxy contract and the contract name can be generated, and the mapping relationship information is stored in the contract management platform. In other words, when the requesting node applies to the blockchain network to generate a proxy contract, in addition to submitting the first address corresponding to the data contract and the second address corresponding to the business contract to the blockchain network, it is also necessary to submit the name of the requested proxy contract, that is, the above-mentioned contract name, to the blockchain network. When the node server receives the contract registration request from the requesting node, it can verify the contract name submitted by the requesting node to detect whether the contract name has been registered. The specific verification process of the contract name includes: using the contract name as a keyword to query the historical mapping relationship information stored in the contract management platform. The historical mapping relationship information refers to the mapping relationship between all proxy contract addresses and corresponding proxy contract names stored in the contract management platform as of the current system time; if it is detected that the contract name submitted by the requesting node already exists in the contract management platform, a name change prompt message can be returned to the requesting node. The name change prompt message can be: the contract name has been registered, please change the contract name and resubmit; if it is detected that the contract name submitted by the requesting node does not exist in the contract management platform, that is, the contract name has not been registered, then the node server can generate a mapping relationship information between the contract name and the third address, and store the mapping relationship information in the contract management platform.

When a requesting node needs to call a certain service, it can send a contract query request to the node server. When the node server receives the contract query request sent by the requesting node, it obtains the contract name carried in the contract query request; obtains a third address that has a mapping relationship with the contract name from the contract management platform, and returns the third address to the requesting node. The requesting node receives the third address returned by the node server and stores the third address and the contract name locally. When the requesting node generates new transaction data, it can upload the stored third address and the new transaction data to the blockchain network. The node server in the blockchain network can obtain the new transaction data and call the proxy contract corresponding to the third address. Based on the proxy contract, it calls the business contract. Further, based on the business logic in the business contract, it operates on the data contract and the new transaction data to generate the contract processing result corresponding to the new transaction data. The new transaction data and contract processing result can be packaged into blocks for on-chain processing.

Optionally, when the node server receives the transaction data uploaded by the requesting node, the node server can also verify the signature of the received transaction data. The specific verification process is as follows: the node server can obtain the digital signature carried by the transaction data and obtain the public key corresponding to the requesting node; decrypt the digital signature based on the public key to obtain the first summary information corresponding to the digital signature; perform a hash operation on the transaction data based on the hash algorithm to obtain the second summary information corresponding to the transaction data; if the first summary information is the same as the second summary information, the transaction data verification is passed. Specifically, in order to prevent the transaction data from being maliciously tampered with during transmission, the requesting node can generate a key pair (including a private key and a public key, the private key is managed by the requesting node itself, and the public key can be notified to all node servers in the blockchain network). The requesting node can use a hash algorithm to perform a hash operation on the transaction data to generate the first summary information corresponding to the transaction data, and use the generated private key to encrypt the first summary information. The encrypted first summary information is the digital signature corresponding to the transaction data. The requesting node uploads the transaction data carrying the digital signature and the third address to the blockchain network. After receiving the transaction data carrying the digital signature uploaded by the requesting node, the node server in the blockchain network can obtain the public key corresponding to the requesting node, decrypt the digital signature according to the public key, and obtain the first summary information corresponding to the digital signature. Then, according to the hash algorithm (that is, the hash algorithm used by the requesting node to generate the digital signature), a hash operation is performed on the transaction data received by the node server to obtain the second summary information corresponding to the received transaction data. If the first summary information is the same as the second summary information, it indicates that the transaction data has not been tampered with during the upload process and the signature verification is passed; if the first summary information is different from the second summary information, it indicates that the transaction data may have been tampered with during the upload process and the signature verification fails.

It should be understood that before uploading transaction data, the requesting node has already notified the node server in the blockchain network of the public key and the hash algorithm used to generate the digital signature. If the transaction data is tampered with during the upload process, the digital signature received by the node server is not the digital signature originally generated by the requesting node. The node server will be unable to decrypt the digital signature using the public key corresponding to the requesting node. Hash algorithms include but are not limited to SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512.

Optionally, after generating a proxy contract, a management node for the proxy contract can be identified. The management node can access the proxy contract and authorize other nodes to access the proxy contract. These other nodes with access to the proxy contract are designated as authorized access nodes. Binding relationships between the proxy contract, the management node, and the authorized nodes are established on the contract management platform. In other words, the contract management platform can maintain mappings between proxy contracts, managers, and authorized access users.

When the node server receives the contract query request sent by the requesting node, it obtains the contract name carried in the contract query request; obtains a third address that has a mapping relationship with the contract name from the contract management platform, and obtains multiple nodes associated with the third address; if the requesting node exists among the multiple nodes, it is determined that the requesting node has query authority (when the requesting node has the authority to access the proxy contract, the requesting node has the authority to query the proxy contract address), and the third address is returned to the requesting node. The requesting node can receive the third address returned by the node server and store the third address and the contract name locally; if the requesting node does not exist among the multiple nodes, it is determined that the requesting node does not have query authority, and permission prompt information is returned to the requesting node. In other words, when the node server receives a contract query request, it can detect whether the requesting node that initiates the contract query request has query authority. If the requesting node is any of the management node and permission access node corresponding to the proxy contract, it is determined that the requesting node has query authority, and the third address corresponding to the contract name is returned to the requesting node; if the requesting node is not included in the management node and permission access node corresponding to the proxy contract, it is determined that the requesting node does not have query authority, and permission prompt information is returned to the requesting node.

Please refer to Figure 4, which is a schematic diagram of a smart contract execution scenario provided by an embodiment of the present application. As shown in Figure 4, the requester (i.e., the requesting node, corresponding to the requesting terminal 10e in the embodiment corresponding to Figure 2) can send a contract query request to a node (such as node 1) in the blockchain network according to the interface provided by the contract management platform. For example, if a user enters the proxy contract name "name aaa" to query the proxy contract address, the requesting terminal corresponding to the user can generate a contract query request and send the generated contract query request to blockchain node 1. After receiving the contract query request sent by the requester, node 1 can search the mapping relationship table stored in the contract management platform for the proxy contract address that has a mapping relationship with "name aaa", such as address a. Node 1 can return address a to the requester and cache it in the requester's local storage. When the requester's local storage has cached the address a corresponding to the proxy contract, the subsequent requester can use it directly when it needs to call the proxy contract without having to query the address corresponding to the proxy contract again. That is, for each proxy contract, only when the requester does not store the corresponding proxy contract address will a contract query request be sent to the node to obtain the corresponding proxy contract address from the contract management platform.

After the requester obtains the returned address a, the requester can call the proxy contract by initiating a transaction, that is, the requester can upload the transaction data carrying address a to node 1 in the blockchain network and request to call the proxy contract corresponding to address a. After receiving the transaction data uploaded by the requester, node 1 can verify the signature of the received transaction data. After the signature is verified, node 1 can call the corresponding proxy contract according to address a, and then call the business contract according to the proxy contract, and process the data contract and transaction data according to the business logic in the business contract, that is, the contract code in the proxy contract can be executed in the Ethereum virtual machine of node 1. The contract code can automatically determine whether the current scenario meets the contract triggering conditions, and strictly implement the contract response rules, and determine whether the transaction data is satisfied according to the contract code execution result. Valid. After the transaction data is verified to be valid, the transaction data can be packaged into a new data block (i.e., block 30a). Node 1 can broadcast block 30a in the blockchain network so that the remaining nodes in the blockchain network can perform consensus verification on block 30a according to the consensus algorithm. When the consensus of block 30a is passed, block 30a can be formally put on the chain. That is, after the consensus is passed, the block height of block 30a can be updated according to the maximum block height in the blockchain stored by node 1, and the updated block 30a can be stored in the local database of node 1. At this time, the updated block 30a is block N+i in the local database of node 1. N+i is used to represent the block order of the updated block 30a in the local blockchain. N and i are both integers greater than or equal to 0.

In an embodiment of the present application, upon receiving a contract registration request from a requesting node, a blockchain node can obtain the contract name, the first address corresponding to the data contract, and the second address corresponding to the business contract carried in the contract registration request, obtain a contract template from the contract management platform, bind the first address and the second address based on the contract template, obtain a proxy contract associated with the data contract and the business contract, generate a third address corresponding to the proxy contract, and store the mapping relationship information between the third address and the contract name in the contract management platform. Thus, by creating a contract management platform in the blockchain and writing a contract template in the contract management platform, the business contract address and the data contract address can be input as parameters into the contract template to bind the data contract and the business contract, completing the deployment process of the proxy contract in the blockchain. The use of contract templates can reduce the development process of proxy contracts, thereby improving the efficiency of contract development in the blockchain.

Please refer to Figure 5, which is a flowchart of another blockchain contract deployment method provided by an embodiment of the present application. As shown in Figure 5, the method may include the following steps:

Step S201: Receive a contract registration request from a requesting node and obtain the contract name, the first address corresponding to the data contract, and the second address corresponding to the business contract carried in the contract registration request; the data contract is used to store business data, and the business contract is used to store business logic;

Step S202: Obtain a contract template from the contract management platform, bind the first address and the second address based on the contract template, obtain a proxy contract associated with the business contract and the data contract, and generate a third address corresponding to the proxy contract;

Step S203: Generate mapping relationship information between the third address and the contract name, and store the mapping relationship information in the contract management platform;

The specific implementation process of step S201 - step S202 can refer to step S101 - step S103 in the embodiment corresponding to FIG3 , and will not be described in detail here.

Step S204: Obtain an update request for the proxy contract, and obtain the first address and the fourth address corresponding to the updated business contract based on the update request;

Specifically, when business requirements change, contracts deployed on the blockchain need to be updated. Since business contracts are separate from data contracts, changes in business requirements only require redeploying the business contract to complete the update of the smart contract on the blockchain. The requesting node can send an update request for the proxy contract to the blockchain node. After receiving the update request from the requesting node, the node server in the blockchain network can obtain the first address associated with the update request and the fourth address corresponding to the updated business contract. The updated business address is used to store the updated business logic, and the fourth address is the updated business contract address determined by the Ethereum Virtual Machine in the node server based on the requesting node's account information after the updated business contract is successfully created.

It should be noted that before sending an update request to the blockchain network, the requesting node also needs to upload the updated business contract written by the developer to the blockchain network and publish it on the blockchain to obtain the fourth address returned. The specific publishing process can be found in the description of step S101 in the embodiment corresponding to Figure 3 above, and will not be repeated here.

Step S205: Input the fourth address and the first address as parameters into the contract template to generate a test proxy contract;

Specifically, the node server can obtain a contract template from the contract management platform and input the first and fourth addresses of the data contract as parameters into the contract template. Using the contract template after inputting the parameters, the method for setting the data contract address can be called from the update business contract corresponding to the fourth address. By inputting the first address into the update business contract, the data contract and the update business contract can be bound to obtain a new proxy contract, which can also become a test proxy contract. The specific generation process of the test proxy contract can be found in the description of the proxy contract generation process in the embodiment corresponding to Figure 3 above, and will not be repeated here.

Step S206: When the test proxy contract passes the test, freeze the proxy contract and update the second address in the proxy contract to the fourth address in the test proxy contract that passed the test;

Specifically, after generating a test proxy contract, it needs to be tested to detect vulnerabilities in the contract code within the test proxy contract. Testing a test proxy contract essentially involves testing its methods. After the test proxy contract is successfully deployed, the node server can call the contract method within the test proxy contract to complete a transaction data processing process. When the transaction data processing results meet the expected results, the test proxy contract has passed. For example, if a transfer transaction is successful, the test proxy contract has passed; if the transfer is unsuccessful, the test proxy contract has failed. If the test proxy contract passes the test, the proxy contract can be frozen in the blockchain, temporarily halting calls to the proxy contract. The second address in the proxy contract is updated to the fourth address in the tested proxy contract. In other words, after the test proxy contract passes the test, the second address of the original business contract in the proxy contract is replaced with the fourth address corresponding to the updated business contract. The updated proxy contract now contains both the first address corresponding to the data contract and the fourth address corresponding to the updated business contract.

Step S207: Determine the proxy contract containing the first address and the fourth address as the updated proxy contract; and associate the updated proxy contract with the third address.

Specifically, after the second address in the proxy contract is replaced with the fourth address corresponding to the updated business contract, the updated proxy contract can be obtained. The address corresponding to the updated proxy contract remains unchanged, still the third address before the update. The updated proxy contract is activated, completing the contract update. It can be seen that the test proxy contract can be tested without affecting existing online businesses. After the test passes, the proxy contract can be frozen and the business contract address in the proxy contract can be updated to complete the contract update process. The updated proxy contract also needs to be formally uploaded to the blockchain and stored.

Please also refer to Figure 6, which is a schematic diagram of a contract upgrade scenario provided by an embodiment of the present application. As shown in Figure 6, the smart contract in the blockchain is interpreted and executed in the Ethereum virtual machine 40a. If a proxy contract 40c has been deployed in the blockchain, the proxy contract 40c is generated by inputting the address 1 corresponding to the data contract 40e and the address 2 corresponding to the business contract 40d as parameters into the contract template in the contract management platform 40b. The proxy contract 40c can call the business contract 40d, and the business contract 40d can call the data contract 40e. When business requirements change, the business contract 40d needs to be updated. The developer can write an updated business contract 40f, and the requesting node uploads the updated business contract 40f to the blockchain network. After the updated business contract 40f is stored in the blockchain, the blockchain node can return the address 3 corresponding to the updated business contract 40f to the requesting node, and then the requesting node can send an update request for the proxy contract 40c to the blockchain node. After receiving the update request, node 1 in the blockchain network can obtain the address 1 and address 3 carried in the update request. Node 1 can obtain the contract template from the contract management platform 40b, input address 1 and address 3 as parameters into the contract template, bind the data contract 40e corresponding to address 1 with the updated business contract 40f corresponding to address 3, and generate a test proxy contract 40g.

Node 1 can test test proxy contract 40g by calling a contract method in test proxy contract 40g, i.e., calling test proxy contract 40g through address 3. Test proxy contract 40g calls update business contract 40f, which in turn calls data contract 40e. For example, calling a contract method in test proxy contract 40g to process a transfer transaction. If the transfer transaction is successful, test proxy contract 40g has passed the test. After test proxy contract 40g passes the test, proxy contract 40c can be frozen, and address 2 in proxy contract 40c can be updated to address 4 in test proxy contract 40g, resulting in an updated proxy contract 40h. In other words, the contract address corresponding to the updated proxy contract 40h is the same as the address corresponding to proxy contract 40c (the address remains unchanged). The updated proxy contract 40h can call update business contract 40f, and update business contract 40f can call data contract 40e. Node 1 can package the updated proxy contract 40h into block 40i. After block 40i passes consensus verification in the blockchain network according to the consensus algorithm, block 40i can be officially put on the chain and stored in the local database 40j of node 1.

In an embodiment of the present application, a proxy contract can be generated by creating a contract management platform in the blockchain and writing a contract template in the contract management platform. The business contract address and the data contract address are input as parameters into the contract template. That is, the blockchain node can bind the data contract and the business contract based on the contract template in the contract management platform to complete the deployment process of the proxy contract in the blockchain. When multiple proxy contracts need to be deployed in the blockchain, multiple proxy contracts can be quickly generated according to the contract template, reducing the development process of the proxy contract, thereby improving the development efficiency of the contract in the blockchain; by updating the business contract address in the proxy contract to the new business contract address, the contract upgrade process can be completed, which can improve the contract upgrade efficiency.

Please refer to Figure 7, which is a schematic diagram of the structure of a blockchain contract deployment device provided in an embodiment of the present application. The blockchain contract deployment device 1 can be applied to a blockchain node. As shown in Figure 7, the blockchain contract deployment device 1 may include: a receiving module 10, a creation module 11, and a storage module 12;

Receiving module 10, used to receive the contract registration request sent by the requesting node, and obtain the contract name, the first address corresponding to the data contract, and the second address corresponding to the business contract carried in the contract registration request; the data contract is used to store business data, and the business contract is used to store business logic;

Creation module 11 is used to obtain a contract template from the contract management platform, bind the first address and the second address based on the contract template, obtain a proxy contract associated with the business contract and the data contract, and generate a third address corresponding to the proxy contract;

The storage module 12 is used to generate mapping relationship information between the third address and the contract name, and store the mapping relationship information in the contract management platform.

The specific functional implementation of the receiving module 10, the creating module 11, and the storing module 12 can refer to steps S101 to S103 in the embodiment corresponding to FIG3 above, and will not be repeated here.

Please refer to FIG7 , the blockchain contract deployment device 1 may further include: a block generation module 13 , a consensus module 14 , an address determination module 15 , a traversal module 16 , a verification module 17 , a query request receiving module 18 , an address query module 19 , a transaction data acquisition module 22 , and a data operation module 23 ;

The block generation module 13 is used to obtain the data contract and business contract uploaded by the requesting node and generate a contract block based on the data contract and business contract;

Consensus module 14 is used to determine the data contract and business contract as being in a successful release state when the contract block is agreed upon in the blockchain network;

An address determination module 15 is configured to determine, based on the account information corresponding to the requesting node, a first address corresponding to the data contract in a successfully published state and a second address corresponding to the business contract in a successfully published state, and send the first address and the second address to the requesting node;

A traversal module 16 is used to traverse the historical mapping relationship information stored in the contract management platform based on the contract name;

Verification module 17, used to return a name change prompt to the requesting node if the contract name exists in the historical mapping relationship information;

The verification module 17 is further configured to generate mapping relationship information between the third address and the contract name if the contract name does not exist in the historical mapping relationship information, and store the mapping relationship information in the contract management platform;

The query request receiving module 18 is used to obtain the contract name carried in the contract query request when receiving the contract query request sent by the requesting node;

An address query module 19 is configured to obtain a third address that is mapped to the contract name from the contract management platform, and return the third address to the requesting node so that the requesting node stores the third address and the contract name locally;

The transaction data acquisition module 22 is used to obtain the transaction data uploaded by the requesting node and obtain the proxy contract based on the third address carried in the transaction data;

The data operation module 23 is used to call the business contract according to the proxy contract, and based on the business logic in the business contract, operate the data contract and transaction data to generate the contract processing result corresponding to the transaction data.

The contract management platform includes an association relationship between a third address and a plurality of nodes, wherein the plurality of nodes include a management node and an authorized access node corresponding to the proxy contract;

The blockchain contract deployment device 1 may further include: an associated node acquisition module 20, a query authority determination module 21;

An associated node acquisition module 20 is configured to acquire a third address that has a mapping relationship with the contract name from the contract management platform, and acquire multiple nodes associated with the third address;

A query authority determination module 21 is configured to determine, if a requesting node exists among the multiple nodes, whether the requesting node has query authority, and return the third address to the requesting node, so that the requesting node stores the third address and the contract name locally;

The query authority determination module 21 is further used to determine that the requesting node does not have the query authority if the requesting node does not exist among the multiple nodes, and return authority prompt information to the requesting node.

The blockchain contract deployment device 1 may further include: an update request acquisition module 24, a test contract generation module 25, and a contract update module 26;

An update request acquisition module 24 is configured to acquire an update request for the proxy contract, and acquire the first address and the fourth address corresponding to the updated business contract based on the update request;

A test contract generation module 25 is configured to input the fourth address and the first address as parameters into a contract template to generate a test proxy contract;

The contract updating module 26 is configured to update the proxy contract based on the tested proxy contract when the test proxy contract passes the test.

Among them, the specific functional implementation of the block generation module 13, the consensus module 14, and the address determination module 15 can refer to step S101 in the embodiment corresponding to Figure 3 above, the specific functional implementation of the traversal module 16 and the verification module 17 can refer to step S103 in the embodiment corresponding to Figure 3 above, the specific functional implementation of the query request receiving module 18, the address query module 19, the associated node acquisition module 20, the query authority determination module 21, the transaction data acquisition module 22, and the data operation module 23 can refer to step S103 in the embodiment corresponding to Figure 3 above and the embodiment corresponding to Figure 4, the specific functional implementation of the update request acquisition module 24, the test contract generation module 25, and the contract update module 26 can refer to steps S204-S207 in the embodiment corresponding to Figure 5 above, and will not be repeated here.

Please refer to FIG7 , the construction module 11 may include: a parameter input unit 111 , an interface calling unit 112 , and a binding unit 113 ;

The parameter input unit 111 is used to obtain a contract template from the contract management platform and input the first address and the second address as parameters into the contract template;

The interface calling unit 112 is configured to call an address setting interface from the business contract corresponding to the second address based on the contract template;

The binding unit 113 is used to input the first address into the business contract according to the address setting interface, bind the business contract and the data contract, and obtain the proxy contract.

The specific functional implementation of the parameter input unit 111, the interface calling unit 112, and the binding unit 113 can be found in step S102 of the embodiment corresponding to FIG. 3 above, and will not be described in detail here.

Please refer to FIG7 , the contract updating module 26 may include: an address updating unit 261 , an updated contract determining unit 262 ;

The address updating unit 261 is used to freeze the proxy contract when the test proxy contract passes the test, and update the second address in the proxy contract to the fourth address in the test proxy contract in the test passed state;

The updated contract determining unit 262 is configured to determine the proxy contract including the first address and the fourth address as an updated proxy contract; the updated proxy contract is associated with the third address.

Among them, the specific functional implementation of the address updating unit 261 and the updated contract determining unit 262 can refer to steps S206 and S207 in the embodiment corresponding to Figure 5 above, and will not be repeated here.

In an embodiment of the present application, a proxy contract can be generated by creating a contract management platform in the blockchain and writing a contract template in the contract management platform. The business contract address and the data contract address are input as parameters into the contract template. That is, the blockchain node can bind the data contract and the business contract based on the contract template in the contract management platform to complete the deployment process of the proxy contract in the blockchain. When multiple proxy contracts need to be deployed in the blockchain, multiple proxy contracts can be quickly generated according to the contract template, reducing the development process of the proxy contract, thereby improving the development efficiency of the contract in the blockchain; by updating the business contract address in the proxy contract to the new business contract address, the contract upgrade process can be completed, which can improve the contract upgrade efficiency.

Please refer to Figure 8, which is a structural diagram of a node device provided in an embodiment of the present application. As shown in Figure 8, the node device 1000 may include: a processor 1001, a network interface 1004 and a memory 1005. In addition, the node device 1000 may also include: a user interface 1003, and at least one communication bus 1002. Among them, the communication bus 1002 is used to realize the connection and communication between these components. Among them, the user interface 1003 may include a display screen (Display), a keyboard (Keyboard), and the optional user interface 1003 may also include a standard wired interface and a wireless interface. The network interface 1004 may optionally include a standard wired interface and a wireless interface (such as a WI-FI interface). The memory 1004 may be a high-speed RAM memory or a non-volatile memory (non-volatile memory), such as at least one disk storage. The memory 1005 may also be at least one storage device located away from the aforementioned processor 1001. As shown in Figure 8, the memory 1005 as a computer-readable storage medium may include an operating system, a network communication module, a user interface module and a device control application.

In the node device 1000 shown in FIG8 , the network interface 1004 can provide network communication functions; the user interface 1003 is mainly used to provide an interface for user input; and the processor 1001 can be used to call the device control application stored in the memory 1005 to achieve:

Receive the contract registration request sent by the requesting node, obtain the contract name, the first address corresponding to the data contract, and the second address corresponding to the business contract carried in the contract registration request; the data contract is used to store business data, and the business contract is used to store business logic;

Obtain a contract template from the contract management platform, bind the first address and the second address based on the contract template, obtain a proxy contract associated with the business contract and the data contract, and generate a third address corresponding to the proxy contract;

Generate mapping relationship information between the third address and the contract name, and store the mapping relationship information in the contract management platform.

It should be understood that the node device 1000 described in the embodiments of the present application can execute the description of the blockchain contract deployment method in any of the embodiments corresponding to Figures 3 and 5 above, and can also execute the description of the blockchain contract deployment device 1 in the embodiment corresponding to Figure 7 above, and will not be repeated here. In addition, the description of the beneficial effects of using the same method will not be repeated here.

In addition, it should be noted that the embodiment of the present application also provides a computer-readable storage medium, and the computer-readable storage medium stores a computer program executed by the aforementioned blockchain contract deployment device 1, and the computer program includes program instructions. When the processor executes the program instructions, it can execute the description of the blockchain contract deployment method in any of the embodiments corresponding to Figures 3 and 5 above. Therefore, it will not be repeated here. In addition, the description of the beneficial effects of using the same method will not be repeated. For technical details not disclosed in the computer-readable storage medium embodiment involved in this application, please refer to the description of the method embodiment of this application.

Those skilled in the art will appreciate that all or part of the processes in the above-described method embodiments can be implemented by instructing related hardware through a computer program. The computer program can be stored in a computer-readable storage medium. When executed, the program can include the processes in the above-described method embodiments. The computer-readable storage medium can be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

The above disclosure is only a preferred embodiment of the present application, and certainly cannot be used to limit the scope of rights of the present application. Therefore, equivalent changes made according to the claims of the present application are still within the scope covered by the present application.

Claims (10)

1. A method for deploying a blockchain contract, characterized in that it includes: The node server creates a contract management platform, obtains a contract template for input address parameters, and adds the contract template to the contract management platform; the contract management platform refers to a smart contract used to implement contract management functions. When the first address corresponding to the data contract and the second address corresponding to the business contract are received, the first address and the second address are input as parameters into the contract template. Through the contract template with the input parameters, a proxy contract associated with the data contract and the business contract is generated. The data contract is used to store business data, and the business contract is used to store business logic. The proxy contract is packaged into a block. When the block containing the proxy contract reaches consensus in the blockchain network, the block containing the proxy contract is uploaded to the blockchain to determine that the proxy contract has been successfully published. 2. The method according to claim 1, characterized in that, the step of packaging the proxy contract into a block, and when the block storing the proxy contract reaches consensus in the blockchain network, performing on-chain processing on the block storing the proxy contract, and determining that the proxy contract is in a successfully published state, includes: The proxy contract is packaged into a block, and the block containing the proxy contract is propagated over the network based on the peer-to-peer transmission method in the blockchain network, so that the blockchain nodes in the blockchain network can perform consensus verification on the block containing the proxy contract. When a consensus is reached on the block containing the proxy contract, the block containing the proxy contract is uploaded to the blockchain to determine that the proxy contract is in a successfully published state. Based on the account information of the requesting node, the third address of the proxy contract in the successfully published state is determined. The requesting node is a device that sends the first address and the second address to the node server. 3. The method according to claim 2, characterized in that it further comprises: Obtain the contract name corresponding to the proxy contract, and verify the contract name in the contract management platform; When the contract name is not registered in the contract management platform, a mapping relationship information between the third address and the contract name is generated, and the mapping relationship is stored in the contract management platform. 4. The method according to claim 2, characterized in that it further comprises: Obtain the management node corresponding to the proxy contract, and establish a binding relationship between the management node and the proxy contract in the contract management platform; the management node is used to access the proxy contract. When the management node receives a message that it has authorized the access rights of the proxy contract to the authorized access node, the binding relationship between the proxy contract and the authorized access node is added in the contract management platform. 5. The method according to claim 2, characterized in that it further comprises: Obtain the transaction data uploaded by the requesting node, and invoke the proxy contract based on the third address carried in the transaction data; The proxy contract calls the business contract, and based on the business logic in the business contract, it operates on the data contract and the transaction data to generate the contract processing result corresponding to the transaction data. The transaction data and the contract processing result are then packaged into a block for on-chain processing. 6. The method according to claim 5, wherein obtaining the transaction data uploaded by the requesting node and invoking the proxy contract based on the third address carried in the transaction data includes: Obtain the transaction data uploaded by the requesting node, and decrypt the digital signature carried by the transaction data according to the public key corresponding to the requesting node to obtain the first digest information corresponding to the digital signature; The transaction data is hashed using a hash algorithm to obtain the second digest information corresponding to the transaction data. If the first digest information is the same as the second digest information, the transaction data verification is successful, and the proxy contract is invoked based on the third address carried by the verified transaction data. 7. The method according to claim 1, characterized in that it further comprises: Obtain the update request for the proxy contract, and based on the update request, obtain the first address and the fourth address corresponding to the updated business contract; Input the fourth address and the first address as parameters into the contract template to generate a test proxy contract; When the test proxy contract passes the test, the proxy contract is updated based on the test proxy contract that passed the test. 8. A blockchain contract deployment device, characterized in that it comprises: A creation module is used by the node server to create a contract management platform, obtain a contract template for input address parameters, and add the contract template to the contract management platform; the contract management platform refers to a smart contract used to implement contract management functions. The creation module is further configured to, when receiving a first address corresponding to a data contract and a second address corresponding to a business contract, input the first address and the second address as parameters into the contract template, and generate a proxy contract associated with the data contract and the business contract through the contract template with the input parameters; the data contract is used to store business data, and the business contract is used to store business logic; The block generation module is used to package the proxy contract into a block. When the block containing the proxy contract reaches consensus in the blockchain network, the block containing the proxy contract is uploaded to the chain to determine that the proxy contract is in a successfully published state. 9. A node device, characterized in that it includes a memory and a processor, the memory storing a computer program, which, when executed by the processor, causes the processor to perform the steps of the method as claimed in any one of claims 1 to 7. 10. A computer-readable storage medium, characterized in that the computer-readable storage medium stores a computer program, the computer program including program instructions, which, when executed by a processor, perform the steps of the method as described in any one of claims 1 to 7.