CN116382710A

CN116382710A - Method for distributing contracts in block chain and block chain link point

Info

Publication number: CN116382710A
Application number: CN202310349450.0A
Authority: CN
Inventors: 杨达一
Original assignee: Ant Blockchain Technology Shanghai Co Ltd
Current assignee: Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2023-03-31
Filing date: 2023-03-31
Publication date: 2023-07-04

Abstract

A method of deploying contracts in a blockchain and blockchain node, the method comprising: receiving a first transaction for deploying a first contract, wherein the first transaction comprises a code identification of a first code and a value of an invariable variable in the first code, and the first code is prestored in a blockchain; storing state data of the first contract in a blockchain according to the first transaction, wherein the state data of the first contract comprises the code identification and the value of the immutable variable.

Description

Method for distributing contracts in block chain and block chain link point

Technical Field

The embodiment of the specification belongs to the technical field of blockchains, and particularly relates to a method for deploying contracts in a blockchain and a blockchain node.

Background

Blockchain (Blockchain) is a new application mode of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanisms, encryption algorithms, and the like. In the blockchain system, data blocks are combined into a chained data structure in a sequential connection mode according to the time sequence, and the distributed account book is guaranteed to be untampered and untrustworthy in a cryptographic mode. Because the blockchain has the characteristics of decentralization, non-tamperability of information, autonomy and the like, the blockchain is also receiving more and more attention and application.

Disclosure of Invention

The present invention aims to provide a scheme for deploying contracts in a blockchain to reduce the resources required for deploying the contracts.

A first aspect of the present specification provides a method of deploying contracts in a blockchain, performed by blockchain points, the method comprising:

receiving a first transaction for deploying a first contract, wherein the first transaction comprises a code identification of a first code and a value of an invariable variable in the first code, and the first code is prestored in a blockchain;

storing state data of the first contract in a blockchain according to the first transaction, wherein the state data of the first contract comprises the code identification and the value of the immutable variable.

A second aspect of the present specification provides a blockchain node comprising:

a receiving unit, configured to receive a first transaction for deploying a first contract, where the first transaction includes a code identifier of a first code and a value of an immutable variable in the first code, and the first code is stored in a blockchain in advance;

a storage unit, configured to store state data of the first contract in a blockchain according to the first transaction, where the state data of the first contract includes the code identifier and a value of the immutable variable.

A third aspect of the present description provides a computer-readable storage medium having stored thereon a computer program which, when executed in a computer, causes the computer to perform the method of the first aspect.

A fourth aspect of the present specification provides a blockchain node comprising a memory having executable code stored therein and a processor that when executing the executable code implements the method of the first aspect.

In the solution provided in the embodiments of the present specification, contracts are deployed by two phases, the first phase being a code storage phase, i.e. first storing the initial code of the contract in the blockchain, in which the immutable variable is not replaced with a specific variable value; the second phase, the contract deployment phase, is to deploy the contract by sending a transaction of deploying the contract to the blockchain, wherein the transaction only comprises the identification of the initial code and the value of the immutable variable, so that the contract is deployed in the blockchain by executing the transaction, and the status data of the contract comprises the identification of the initial code and the value of the immutable variable. By doing so, the overhead of a user deploying a contract is reduced, as well as the storage resources required to store contract state data.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings that are needed in the description of the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments described in the present disclosure, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a schematic diagram of deploying a smart contract in one embodiment;

FIG. 2 is a diagram of invoking a smart contract in one embodiment;

FIG. 3 is a schematic diagram of a block chain data storage structure in one embodiment;

FIG. 4 is a flow chart of a method of storing contract initiation code in an embodiment of the present disclosure;

FIG. 5 is a flow chart of a method of deploying contracts in an embodiment of the present description;

FIG. 6 is a schematic diagram of a state store of contracts in an embodiment of the present description;

FIG. 7 is a flow chart of a method of invoking a contract in an embodiment of the present disclosure;

fig. 8 is a block chain node block diagram in an embodiment of the present disclosure.

Detailed Description

In order to make the technical solutions in the present specification better understood by those skilled in the art, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only some embodiments of the present specification, not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are intended to be within the scope of the present disclosure.

Blockchains are generally divided into three types: public chains (Public Blockchain), private chains (Private Blockchain) and federated chains (Consortium Blockchain). In addition, there are many types of combinations, such as different combinations of private chain+federation chain, federation chain+public chain, and the like. Among them, the highest degree of decentralization is the public chain. The public chain is represented by bitcoin and ethernet, and participants joining the public chain can read data records on the chain, participate in transactions, compete for accounting rights of new blocks, and the like. Moreover, each participant (embodied as a node of the participant on the blockchain) is free to join and leave the network and perform related operations. The private chain is the opposite, the write rights of the network are controlled by an organization or organization, and the data read rights are specified by the organization. In short, the private chain may be a weakly centralized system with few and strict restrictions on participating nodes. This type of blockchain is more suitable for use within a particular organization. The alliance chain is a block chain between public and private chains, and can realize 'partial decentralization'. Each node in the federation chain typically has an entity organization or organization corresponding thereto; participants join the network by authorization and form a benefit-related federation, collectively maintaining blockchain operation.

Whether public, private, or federated, most may provide the functionality of smart contracts. Intelligent contracts on blockchains are contracts on blockchain systems that can be executed by transaction triggers. The smart contracts may be defined in the form of codes.

Taking the ethernet as an example, support users create and invoke some complex logic in the ethernet network, which is the biggest challenge for ethernet to distinguish from the bitcoin blockchain technology. At the heart of the ethernet as a programmable blockchain is an Ethernet Virtual Machine (EVM), which can be run by each ethernet node. The EVM is a graphics-complete virtual machine, meaning that various complex logic can be implemented by it. The user's issuing and invoking of the smart contract in the ethernet is running on the EVM. In practice, the virtual machine runs directly on virtual machine code (virtual machine bytecode, hereinafter "bytecode"). The intelligent contracts deployed on the blockchain may be in the form of bytecodes.

FIG. 1 is a schematic diagram of deploying a smart contract in an embodiment. As shown in fig. 1, bob sends a transaction containing information to create a smart contract to the ethernet network, the EVM of node 1 may execute the transaction and generate the corresponding contract instance. "0x6f8ae93 …" in fig. 1 represents the address of this contract, the data field of the transaction may hold byte code, and the to field of the transaction is an empty account. After agreement is reached between nodes through a consensus mechanism, the contract is successfully deployed, and subsequent users can call the contract.

After successful deployment of the contract, a contract account corresponding to the smart contract appears on the blockchain and has a specific address, and the contract code and account store are stored in the contract account. The behavior of the smart contract is controlled by the contract code, and the account store of the smart contract maintains the state of the contract. In other words, the smart contract causes a virtual account to be generated on the blockchain that includes a contract code and an account store (Storage).

The aforementioned, the data field containing the transaction that created the smart contract may include the bytecode of the smart contract. Bytecode consists of a series of bytes, each of which can identify an operation. Based on various aspects of development efficiency, readability and the like, a developer can select a high-level language to write intelligent contract codes instead of directly writing byte codes. The intelligent contract code written in the high-level language is compiled by a compiler to generate byte codes, and then the byte codes can be deployed on a blockchain. The high-level languages supported by ethernet are numerous, such as Solidity, serpent, LLL language.

Taking the Solidity language as an example, the contracts written therewith are very similar to classes (classes) in an object-oriented programming language, and multiple members (or objects) may be declared in one contract, including state variables, functions, function modifiers, events, and the like. The state variable is a value stored in an account store of the smart contract for saving the state of the contract.

The following is code example 1 of a simple smart contract written in the solubility language:

in the above code example 1, line 2 states the state variable storedData of the character type (string), line 3 states an event (event) whose stored contents are the address of the initiator calling the contract and the character string s. Lines 4-7 define a set function, the reference being the string s. The set function performs operations including setting an entry to the state variable storedData, generating an event whose contents include the address of the initiator calling the contract and the string s.

As previously mentioned, the state variables will ultimately be stored in a database. The events generated are typically of the form:

[topic1][topic2]...[topicn][data]

here, the first topic, that is, topic1, is generally a default value, for example, an identifier of the receipt, and may be a hash value obtained by sequentially concatenating the event name, the event parameter type, and the like. Whether or not each of topic2 to topicn is present depends on whether or not an indised modification is added when defining the parameter, and the value of this parameter will then be one of the topics in the license, and the data will typically be put in without an indised modification. In the example of code example 1 above, when event is declared on line 3, both parameters address from and s, without an index modification, will typically be put into data. The code of line 6 sets the data content in the event [ msg.sender, s ] through a store () event. Thus, for the event of line 6 operation, the overall form is:

[ topic1: event identification ] [ data: msg.sender, s ]

Lines 8-10 define the get function. The operation of the function includes returning the value of the queried storedData. returns (string) indicates the type of return value and the constant modifier identifies that the function cannot modify the value of a state variable in the contract.

Further, taking the ethernet as an example, bob sends a transaction containing call intelligent contract information to the ethernet network, as shown in fig. 2, the EVM of node 1 may execute the transaction and generate the corresponding contract instance. In fig. 2, the from field of the transaction is the address of the account that initiates the call to the smart contract, the "0x6f8ae93 …" in the to field represents the address of the called smart contract, and the data field of the transaction holds the method and parameters for calling the smart contract. After invoking the smart contract, the value of the stoneddata may change. Subsequently, a client may view the current value of storedData through a blockchain node (e.g., node 6 in fig. 2).

The intelligent contract can be independently executed at each node in the blockchain network in a specified mode, all execution records and data are stored on the blockchain, so that when the transaction is completed, transaction credentials which cannot be tampered and cannot be lost are stored on the blockchain.

As previously mentioned, the storedData in the above example is a state variable that is stored in the account store of the smart contract. In various blockchain networks that introduce smart contracts, for example, ethernet, accounts may generally include two types:

contract account (contact account): storing the executed smart contract code and the values of the states in the smart contract code, typically only activated by external account calls;

external account (Externally owned account): an account of the user.

The design of external accounts and contracted accounts is actually a mapping of account addresses to account states. The state of an account typically includes fields Nonce, balance, storage root, codeHash, etc. Nonce, balance exist in both external and contracted accounts. The CodeHash and Storage root attributes are generally valid only on contract accounts.

Nonce: a counter. For an external account, this number may represent the number of transactions sent from the account address; for a contract account, there may be a number of contracts that the account creates.

Balance: account balance.

Storage root: a hash of the root node of the MPT tree, the MPT tree organizing the storage of state variables for the closing account.

CodeHash: hash value of smart contract code. For a contract account, this is the hash value of the smart contract; for external accounts, the CodeHash field may typically be an empty string/all 0 string, since no smart contracts are included.

MPT, collectively Merkle Patricia Tree, is a Tree-like structure that combines Merkle Tree and Patricia Tree (compressed prefix Tree, a more space-efficient Trie, dictionary Tree). The Merkle Tree algorithm calculates a Hash value for each transaction, then the two-by-two connections calculate the Hash again, up to the top-most Merkle root. Improved MPT trees, such as 16-ary tree structures, also commonly referred to simply as MPT trees, are employed in ethernet.

The data structure of the ethernet MPT tree includes a state tree (state trie). The state tree contains a key-value pair (key and value pair, also written as key-value, abbreviated as k-v or kv) of the stored content corresponding to each account in the ethernet network. The "key" in the state tree may be a 160bits identifier (e.g., an address of an ethernet account or a portion of a hash value of an address, collectively referred to below as an account address), which is distributed in storage from the root node to the leaf node of the state tree. The "value" in the state tree is generated by encoding the information of the ethernet account (using Recursive-Length Prefix encoding, RLP) method. As previously described, for external accounts, the values include nonces and policies; for a contract account, the values include nonce, balance, codehash and storageoot.

The contract account is used to store smart contract-related status. After the intelligent contracts are deployed on the blockchain, a corresponding contract account is generated. This contract account will typically have states defined by state variables in the smart contract and which will generate new values when the smart contract is executed. The smart contract generally refers to a contract defined in a code form in a blockchain environment that is capable of automatically executing terms. The code may be executed automatically once some event triggers a term in the contract (execution condition is met). In the blockchain, the relevant states of the contract are stored in the storage trie, and the hash value of the root node of the storage trie is stored in the storage trie, so that all states of the contract are locked under the contract account through the hash. The storage trie is also an MPT tree structure, storing key-value mappings of state addresses to state values. The partial information from the root node of the storage trie tree to the leaf node storing the state value is sequentially arranged to store the address of a state.

FIG. 3 is a schematic diagram of a blockchain data store. As shown in fig. 3, the Block header of each Block includes several fields, such as a previous Block Hash (Prev Hash in the figure), a random number Nonce, a Timestamp, a Block number Block Num, a State Root Hash state_root, a Transaction Root Hash transaction_root, a Receipt Root Hash receipt_root, and the like. The Prev Hash in the block header of the next block (e.g., block n+1) points to the previous block (e.g., block N), which is the Hash value of the previous block. In this way, the lock of the next block to the previous block is achieved by the block header on the blockchain. Wherein State_ Root, transaction _root and Receipt_root lock the State set, transaction set and Receipt set, respectively. The status set, transaction set, and receipt set organize the status, transaction, and receipt, respectively, in a tree form. In general, the tree structures may be the same or different. For example, in ethernet, the same MPT structure is used. In some tree structures, such as ethernet, that include a state set of smart contracts, a two-level MPT structure is included: the leaf nodes of the MPT structure of the upper level comprise two types of external accounts and contract accounts; each of the contract accounts includes a next-level MPT structure, with the next-level leaf nodes including values for states in the contract accounts.

Still taking the ethernet as an example, as shown in fig. 3, the state_root may be a hash value of the root of the MPT tree composed of the states of all accounts in the current block, that is, a state tree state trie pointing to the state_root in the form of one MPT. The root Node of the MPT tree is typically an Extension Node (Extension Node) or a Branch Node (Branch Node), and the hash value of the root Node is typically stored in the state_root. The root Node may be connected to one or more layers of Extension Node/Branch Node below, which may be collectively referred to as intermediate nodes (international nodes). The account address can be formed by connecting a part of values in each node from the root node of the MPT to the leaf node in series in sequence and used as a key, and the account information stored in the leaf node is the value corresponding to the account address, so that a key-value key value pair is formed. This key may also be a part of sha3 (Address) and taken, that is, a part of a hash value of the Account Address (the hash algorithm, for example, employs sha3 algorithm), and the stored value may be rlp (Account), that is, rlp codes of Account information. Wherein the account information is a quadruple of [ nonce, balance, storageRoot, codeHash ]. As previously described, for external accounts, there are typically only two terms, nonce and balance, while the storageRoot, codeHash field stores empty/all 0 strings by default. That is, the external account does not store the contract, nor the state variables generated after execution of the contract. The contract accounts typically include Nonce, balance, storage root, codeHash. Where Nonce is the transaction counter of the contract account; balance is the account Balance; the Storage root corresponds to another MPT, and can be linked to the information of the contract-related state through the Storage root; codeHash is the hash value of the contract code. Whether an external account or a contracted account, its account information is typically located in a separate Leaf Node. From the Extension Node/Branch Node of the root Node to the Leaf Node of each account, several Branch nodes and Extension nodes may be passed in the middle.

The state trie may be a tree in the form of an MPT, typically a 16-ary tree, i.e. there may be up to 16 child nodes per level. For Extension Node, for storing a common prefix, there are typically 1 child Node, which may be a Branch Node. For a Branch Node, there may be a maximum of 16 child nodes, which may include Extension nodes and/or Leaf nodes.

Wherein, for one contract account in the state trie, its store_root points to another tree, which is also in MPT form, in which the data of the state variable (state variable) involved in contract execution is stored. This storage_root points to the MPT form of the tree as the hash value of the Storage Trie, i.e., the Root node of the Storage Trie. Typically, this Storage Trie also stores key-value pairs. The key indicates the address of the state variable, and the value thereof may be the result obtained by processing the position (value counted from 0) of the state variable declaration in the contract through a certain rule, for example, sha3 (position of the state variable declaration), or sha3 (contract name+position of the state variable declaration). value is used to store the value of the state variable (e.g., RLP encoded value). A part of data stored on a path from a root node to a leaf node via an intermediate node is concatenated to form a key, and a value is stored in the leaf node. As mentioned above, this Storage trie may also be a tree in MPT form, typically also a 16-ary tree, i.e. for a Branch Node it may have a maximum of 16 child nodes, which may include Extension nodes and/or Leaf nodes. While for Extension Node, there may be generally 1 child Node, which may be a Branch Node or a Leaf Node.

Such as state Trie Leaf Node Account P in fig. 3, which is a contract account whose Storage Root locks all states in the contract store. These states are organized as MPT trees, tree structures such as the Storage trie linked by the Storage Root. In this linked Storage trie, leaf Node State Variable N is exemplified as a value of the aforementioned contract code, for example, the key may be, for example, and not limited to, sha3 (a declaration location of the cureddata), and the value is s (for brevity, a coding format of the value is omitted here, for example, RLP, and the following is similar, and will not be repeated). Wherein the values of the keys are sequentially distributed from the root node to the leaf node (Leaf Node Variable N) of the storage Trie.

As described above, after a transaction for creating a smart contract is sent onto the blockchain, the blockchain nodes may execute the transaction after consensus is reached for the transaction in the blockchain. At this time, a contract account (including, for example, the Identity of the account, the hash value Codehash of the contract, the root Storage root of the contract) corresponding to the smart contract appears on the blockchain, and has a specific address, and the contract code and the account Storage can be stored in the Storage (Storage) of the contract account. The behavior of the smart contract is controlled by the contract code, and the account store of the smart contract maintains the state of the contract. In other words, the smart contract causes a virtual account to be generated on the blockchain that includes a contract code and an account store (Storage). For a contract deployment transaction or a contract update transaction, the value of the Codehash will be generated or changed. Subsequently, the blockchain node may receive a transaction request invoking the deployed smart contract, which may include an address of the invoked contract, a function in the invoked contract, and the entered parameters. Generally, after the transaction request is commonly identified, each node of the blockchain can independently execute the intelligent contract of the appointed call.

In the deployment contract, the root stored in the contract may be a default value or a hash value calculated according to the root node of the lower storage Trie. This is generally dependent on whether an initialization operation, such as executing a constructor in a contract, will take place in the deployed contract. If the deployed contracts contain constructors, this will typically involve initializing some state variables that will ultimately be stored in the underlying database, which can be performed at the virtual machine. After the initialized state variables, as described in the foregoing, an MPT tree may be constructed, so that a root node of the MPT tree may be obtained, and further, a hash value of the root node may be obtained. If no constructors are included in the deployed contracts, no specific function may be performed, but instead the blockchain platform assigns a StorageRoot a default value, such as a hash value of the empty content.

After the contract is deployed, the contract may be subsequently invoked, as previously described. After Bob initiates a transaction to invoke the smart contract to the ethernet network as shown in fig. 2, the contract executes, setting the state variable to the string "hello". A transaction, such as one of the invoking contracts in fig. 2, is sent into the blockchain network and after consensus, each node may execute the transaction. The to field of the transaction indicates the address of the invoked contract. Any node can find the storage of the contract account according to the address of the contract, and then can read the Codehash according to the storage of the contract account, so that the corresponding contract byte code is found according to the Codehash. The node may load the bytecode of the contract from storage into the virtual machine to execute the contract.

The ethernet gateway also supports the inclusion of immutable variables (immutable) in the contract. The value of the immutable variable in the contract is set at the time of contract deployment and will not be modifiable after the contract deployment is completed. When the virtual machine performs a transaction for deploying a contract, the value of the immutable variable in the contract code may be determined by an instruction in the constructor included in the contract code, the instruction indicating, for example, an incoming parameter of the constructor, so that the virtual machine may determine the value of the immutable variable as the incoming parameter. Specifically, when executing a transaction for deploying a contract, the virtual machine replaces an immutable variable in the other function code with a value (e.g., an incoming parameter) indicated in the constructor by executing the constructor in the contract code, and stores the code of the updated other function as the contract code in the blockchain. This means that if two contracts use the same bytecode even before deployment, but they set different values of immutable variables, the contract code that the two contracts deploy into the blockchain is different.

For contracts that include immutable variables, the present description embodiments deploy the contract through two phases, the first phase being a code storage phase, i.e., first storing the initial code of the contract in the blockchain, in which the immutable variable is not replaced with a specific variable value; the second phase, the contract deployment phase, is to deploy the contract by sending a transaction of deploying the contract to the blockchain, wherein the transaction only comprises the identification of the initial code and the value of the immutable variable, so that the contract is deployed in the blockchain by executing the transaction, and the status data of the contract comprises the identification of the initial code and the value of the immutable variable. By doing so, the overhead of a user deploying a contract is reduced, as well as the storage resources required to store contract state data.

Fig. 4 is a flowchart of a method of storing contract initial code in an embodiment of the present description. The method may be performed by any block link point.

As shown in fig. 4, at S410, the block link point receives a transaction Tx1 for storing a contract initial code, the transaction Tx1 including the contract initial code and a code identification of the contract initial code.

To deploy a contract, a contract deployer may first perform the first phase described above, namely sending a transaction Tx1 to the blockchain for storing the contract initial code, so that each node of the blockchain can receive the transaction Tx1. In another case, the first phase may be performed by the initial code publisher, sending transaction Tx1 to the blockchain. After the initial code publisher sends transaction Tx1 to the blockchain and stores the initial code into the blockchain, the initial code and its code identification may be published at a particular publishing platform so that the contract deployer may deploy the contract based on the code identification according to its own needs.

As described above, the contract initiation code includes an identification of the immutable variable without replacing the immutable variable with a specific variable value. Specifically, the contract initial code includes, for example, a constructor, a function method1, and a function method2. Wherein the function method1 and/or the function method2 comprise an identification of one or more immutable variables, including immutable variable immutable 1, for example.

In one embodiment, a system contract for storing contract initial code is pre-deployed in a blockchain. In one embodiment, the system contract may be deployed in an authoring block. The transaction Tx1 may call a function in the system contract for storing data and take the contract initial code and its identification as the incoming parameters of the function. Wherein, in one embodiment, the identification of the contract initial code may be a code hash value of the contract initial code. In another embodiment, the identifier of the contract initial code may be a character string which is easy to identify, for example, "code1", and by setting the identifier of the contract initial code in this way, two contract initial codes with different identifiers and identical codes may be stored in the blockchain, for example, two identical initial codes with "code1" and "code2" as identifiers are stored, so that different updates or upgrades may be conveniently performed on the two initial codes.

Specifically, in one embodiment, transaction Tx1 is of the form:

{Transaction Tx1

From:Alice(0xf53…)

To:SystemContract

Data:{storage(),code1,“code1”}

}

here, assuming that systemContract represents a contract address of a system contract, storage () is a function for storing a contract initial code in the system contract, code1 is an initial code of contract1, and "code1" is a code identification of code 1.

In another embodiment, transaction Tx1 has the form:

{Transaction Tx1

From:Alice(0xf53…)

To:SystemContract

Data:{storage()；code1,“code1”,“code2”}

}

wherein, both "code1" and "code2" are code identifications of code1 for storing two codes of code1 in the blockchain, the two codes being stored in association with "code1" and "code2", respectively.

It will be appreciated that embodiments of the present description are not limited to storing contract initiation code through the process described above, and in another implementation, a blockchain node may store contract initiation code and its code identification into a blockchain by sending a normal transaction to the blockchain (i.e., a transaction that does not invoke a contract).

At S420, the blockchain link point stores the contract initial code and its code identification in association in the blockchain according to transaction Tx1.

After consensus for transaction Tx1 is reached in the blockchain, each node of the blockchain performs transaction Tx1 separately. After completing execution of transaction Tx1, the blockchain node stores the contract initial code and its code identification in association in the blockchain according to the execution result of transaction Tx1.

Specifically, in the case of invoking the above system contract in the transaction Tx1, the block link point stores the contract initial code and its code identification in association in the contract state of the system contract according to the execution result of the transaction Tx1. Storing the contract initial code and its code identification by association allows the contract initial code stored in association with the code identification to be read in the blockchain based on the code identification.

In one embodiment, only code identification "code1" is included in transaction Tx1, and the blockchain node associates storing code1 with code identification "code1" in the blockchain after completing execution of transaction Tx 1.

In another manner, code identifications "code1" and "code2" are included in transaction Tx1, and the blockchain link stores one copy of code1 in association with code identification "code1" into the blockchain, and another copy of code1 is obtained by copying code1, and the other copy of code1 is stored in association with code identification "code2" into the blockchain. In this way, a deployer of the system contract may update or upgrade the two code codes 1 differently by invoking the system contract.

After completing the first phase, the contract deployer may deploy the contract through the second phase.

Fig. 5 is a flow chart of a method of deploying contracts in an embodiment of the present description. The method may be performed by any blockchain node in the blockchain.

Referring to fig. 5, at S510, the block link point receives a transaction Tx2 for deploying a contract, the transaction Tx2 including a code identification and a value of an immutable variable therein.

As described above, in the embodiment of the present disclosure, the contracts are deployed in a two-stage manner, so when the contracts are deployed, the initial codes corresponding to the contracts are already stored in the blockchain, and the contract deployer only needs to obtain the code identifier of the initial code corresponding to the contract to be deployed, so that the contracts can be deployed without including the contract initial codes in the transaction of deploying the contracts.

For example, transaction Tx2 includes the form as follows:

{Transaction Tx2

From:Bob(0xf53…)

To:null

Data:“code1”；immut1＝V1

}

where "code1" is a code identification of code1, immut1 is an identification of an immutable variable in code1, and V1 is a value of immutable variable immutable 1. That is, a difference from the transaction for deploying contracts shown in fig. 1 is that the contract code is not included in the transaction Tx2, but only the code identification "code1" of the contract initial code, and the value V1 of the immutable variable immutable 1 in the initial code are included. By doing so, the amount of data for transaction Tx2 is greatly reduced compared to the amount of transaction data in fig. 1, thereby reducing the communication bandwidth resources occupied in the blockchain for broadcasting transaction Tx2, reducing the computational resources expended by the blockchain node for verifying the transaction signature, and so on. In addition, from the user's perspective, contract deployers typically need to spend resources in the blockchain (e.g., gas in ethernet) to send transactions to the blockchain, and the amount of gas spent is positively correlated with the amount of transaction data sent, greatly reducing the blockchain user's overhead by reducing the amount of transaction data.

It will be appreciated that the form of transaction Tx2 described above is only an example, and the transaction for deploying a contract in the embodiments of the present specification is not limited thereto, for example, in one case, the value of the immutable variable is set equal to the value of the transaction sender (i.e., from field) in the constructor in the initial code of the contract, so that no assignment of value to the immutable variable is required in the transaction for deploying the contract. In another embodiment, transaction Tx2 may call, for example, a reply function in a system contract for deploying the contract, which may write the state data of the deployed contract in a state database by calling a platform interface.

At S520, the block link point stores state data of the Contract contact 1 according to the transaction Tx2, including the code identification and the value of the immutable variable therein.

As described above, after a transaction for deploying a smart contract is sent onto the blockchain, the blockchain nodes may execute the transaction after consensus is reached for the transaction in the blockchain. Assuming that the transaction Tx2 is used to deploy the Contract contact 1, the block link point may generate a Contract address corresponding to the Contract contact 1 according to the transaction Tx2, add a leaf node corresponding to the Contract address to the above-mentioned state tree according to the Contract address corresponding to the Contract contact 1, and store the account state (or state storage) of the Contract contact 1 in the leaf node.

Fig. 6 is a schematic diagram of state storage of contracts in an embodiment of the present description. As shown in fig. 6, the status store of the contract1 generated from transaction Tx2 may include the following fields: nonce, balance Storage hash, ref, immut. The Nonce, balance and Storage hash fields are the same as the same fields in the contract state store shown in fig. 3, and will not be described here again. Unlike the Contract state store in FIG. 3, the Contract1 state store also includes a Ref field and an Immut field, where the Ref field is an identification of the Contract code referenced by the Contract Contract1 (e.g., "code 1"), and the Immut field includes a value (e.g., V1) of an immutable variable (e.g., immut 1) in the Contract Contract 1. In addition, the code hash field is not included in the state storage of the Contract contact 1, that is, the Contract code is not additionally stored in the deployment Contract contact 1, and thus, the code hash value is not required to be included in the state storage of the Contract contact 1.

As shown in FIG. 6, the Contract deployer may also deploy contracts Contract2 and Contract Contract3, which refer to code1 code, in the blockchain in the same manner. That is, the Ref field in the Contract contact 2 and in the Contract contact 3 are both code1, which means that the contracts contact 1-contact 3 refer to the same Contract initial code, but the value of the immutable variable Immut1 in the contracts contact 1-contact 3 is different. As can be seen from fig. 6, in the method of the embodiment of the present specification, in the case of deploying a plurality of contracts referring to the same contract initial code, only one contract initial code need be stored, and a plurality of final codes (which are codes obtained by replacing an invariable variable in the initial code with a variable value) corresponding to the respective contracts need not be stored, thereby reducing the amount of code data to be stored and saving storage resources.

It will be appreciated that the contract state store shown in FIG. 6 may be applicable to contracts that require setting of immutable variable values, and contracts that do not require setting of immutable variable values may continue to use the state store as shown in FIG. 3.

Fig. 7 is a flowchart of a method for invoking a contract in an embodiment of the present disclosure. The method is applicable to contracts having a state store as shown in fig. 6, and is described below by taking Contract1 as an example.

As shown in fig. 7, at S710, a transaction for invoking a contract is received.

When a blockchain user (e.g., bob) wishes to invoke Contract1, a transaction Tx3 invoking Contract1 may be sent to the blockchain. For example, transaction Tx3 includes the form as follows:

{Transaction Tx3

From:Bob(0xf53…)

To:Contract1

Data:{method1；arg}

}

wherein the transaction Tx3 calls the function method1 in the Contract contact 1, and similarly To the transaction of calling the Contract shown in FIG. 2, the From field of the transaction Tx3 is Bob, the To field is the Contract address of the Contract contact 1, the Data field is the function name of the function method1, and the incoming parameters (arg) To the function method 1.

After user Bob sends transaction Tx3 into the blockchain, the transaction Tx3 is broadcast in the blockchain so that each blockchain node can receive transaction Tx3 to perform transaction Tx3.

At S720, the block link point reads the status data of Contract1, including the code identification and the value of the immutable variable as described above, according to transaction Tx3.

When executing the transaction Tx3, the blockchain node reads the state data of the Contract contact 1 from the state database of the blockchain, i.e., the state store of the Contract contact 1 as shown in fig. 6, according to the Contract address of the Contract contact 1 in the transaction Tx3, and the state store of the Contract contact 1 includes the code identifier "ref=code1" and the value of the immutable variable "immutat1=v1" as shown in fig. 6.

At S730, the blockchain node reads the contract initial code from the blockchain based on the code identification.

After acquiring the code identifier "code1" of the Contract contact 1, the blockchain node may read the Contract initial code corresponding to "code1" from the blockchain according to the code identifier. The initial Contract code is stored in the Contract state of the system Contract, for example, the blockchain node can read the Contract state of the system Contract according to the preset Contract address of the system Contract, and the code stored in association with the code identifier code1 is read from the Contract state, namely, the initial Contract code of the Contract contact 1.

At S740, the Contract1 is executed based on the Contract initial code of the Contract1 and the value of the immutable variable.

After obtaining the initial code of the Contract contact 1, the blockchain node replaces the immutable variable in the initial code with the value of the immutable variable in the state storage of the Contract contact 1, so that the final code of the Contract contact 1 is obtained, and the blockchain node can execute the Contract contact 1 based on the final code.

Specifically, according to the call to the function method1 in the transaction Tx3, the blockchain node may obtain the initial code of the function method1 in the initial code, replace the immutable variable (e.g., immutable 1) in the initial code of the function method1 with the value V1 of immutable 1 in the state storage, and obtain the final code of the function method 1. The blockchain node may then substitute the final code of the incoming parameter execution function mehtod1 in the transaction Tx3, thereby completing the execution of the transaction Tx 3.

FIG. 8 is a block chain node block diagram in an embodiment of the present disclosure, comprising:

a receiving unit 81 for receiving a first transaction for deploying a first contract, wherein the first transaction includes a code identifier of a first code and a value of an immutable variable in the first code, and the first code is stored in a blockchain in advance;

a storage unit 82 for storing state data of the first contract in a blockchain according to the first transaction, the state data of the first contract including the code identification and the value of the immutable variable.

The present description also provides a computer-readable storage medium having stored thereon a computer program which, when executed in a computer, causes the computer to perform the method shown in fig. 4, 5 or 7.

Embodiments of the present disclosure also provide a blockchain node, including a memory and a processor, where the memory stores executable code, and the processor implements the method shown in fig. 4, 5, or 7 when executing the executable code.

In the 90 s of the 20 th century, improvements to one technology could clearly be distinguished as improvements in hardware (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) or software (improvements to the process flow). However, with the development of technology, many improvements of the current method flows can be regarded as direct improvements of hardware circuit structures. Designers almost always obtain corresponding hardware circuit structures by programming improved method flows into hardware circuits. Therefore, an improvement of a method flow cannot be said to be realized by a hardware entity module. For example, a programmable logic device (Programmable Logic Device, PLD) (e.g., field programmable gate array (Field Programmable Gate Array, FPGA)) is an integrated circuit whose logic function is determined by the programming of the device by a user. A designer programs to "integrate" a digital system onto a PLD without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Moreover, nowadays, instead of manually manufacturing integrated circuit chips, such programming is mostly implemented by using "logic compiler" software, which is similar to the software compiler used in program development and writing, and the original code before the compiling is also written in a specific programming language, which is called hardware description language (Hardware Description Language, HDL), but not just one of the hdds, but a plurality of kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), lava, lola, myHDL, PALASM, RHDL (Ruby Hardware Description Language), etc., VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog are currently most commonly used. It will also be apparent to those skilled in the art that a hardware circuit implementing the logic method flow can be readily obtained by merely slightly programming the method flow into an integrated circuit using several of the hardware description languages described above.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, application specific integrated circuits (Application Specific Integrated Circuit, ASIC), programmable logic controllers, and embedded microcontrollers, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, atmel AT91SAM, microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic of the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller in a pure computer readable program code, it is well possible to implement the same functionality by logically programming the method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. Such a controller may thus be regarded as a kind of hardware component, and means for performing various functions included therein may also be regarded as structures within the hardware component. Or even means for achieving the various functions may be regarded as either software modules implementing the methods or structures within hardware components.

The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. One typical implementation device is a server system. Of course, the present application does not exclude that as future computer technology evolves, the computer implementing the functions of the above-described embodiments may be, for example, a personal computer, a laptop computer, a car-mounted human-computer interaction device, a cellular telephone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

Although one or more embodiments of the present description provide method operational steps as described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps recited in the embodiments is merely one way of performing the order of steps and does not represent a unique order of execution. When implemented in an actual device or end product, the instructions may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even in a distributed data processing environment) as illustrated by the embodiments or by the figures. The terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, it is not excluded that additional identical or equivalent elements may be present in a process, method, article, or apparatus that comprises a described element. For example, if first, second, etc. words are used to indicate a name, but not any particular order.

For convenience of description, the above devices are described as being functionally divided into various modules, respectively. Of course, when one or more of the present description is implemented, the functions of each module may be implemented in the same piece or pieces of software and/or hardware, or a module that implements the same function may be implemented by a plurality of sub-modules or a combination of sub-units, or the like. The above-described apparatus embodiments are merely illustrative, for example, the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, for example, multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

In one typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory. The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media. Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, read only compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.

One skilled in the relevant art will recognize that one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Moreover, one or more embodiments of the present description can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

One or more embodiments of the present specification may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. One or more embodiments of the present specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for system embodiments, since they are substantially similar to method embodiments, the description is relatively simple, as relevant to see a section of the description of method embodiments. In the description of the present specification, a description referring to terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the present specification. In this specification, schematic representations of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, the different embodiments or examples described in this specification and the features of the different embodiments or examples may be combined and combined by those skilled in the art without contradiction.

The foregoing is merely an example of one or more embodiments of the present specification and is not intended to limit the one or more embodiments of the present specification. Various modifications and alterations to one or more embodiments of this description will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement, or the like, which is within the spirit and principles of the present specification, should be included in the scope of the claims.

Claims

1. A method of deploying contracts in a blockchain, performed by blockchain links points, the method comprising:

2. The method of claim 1, comprising a first field in the state data of the first contract for storing the code identification.

3. A method according to claim 1 or 2, comprising a second field in the state data of the first contract for storing the value of the immutable variable.

4. The method of claim 1 or 2, further comprising in the first transaction a value of a state variable in the first code, the state data of the first contract comprising a storage root, the storage root generated based on the value of the state variable.

5. A method according to claim 3, further comprising:

receiving a second transaction for storing the first code, the second transaction including the code identification and the first code;

the code identification is stored in association with the first code into a blockchain in accordance with the second transaction.

6. The method of claim 5, the second transaction invoking a system contract, the storing the code identification in association with the first code into a blockchain in accordance with the second transaction comprising: storing the code identification in association with the first code in status data of the system contract in accordance with the second transaction,

the method further comprises the steps of: receiving a third transaction for updating the first code;

updating the first code in the state data of the system contract according to the third transaction.

7. The method of claim 6, the second transaction including the first code, a first code identification of the first code, and a second code identification, the storing the code identification into a blockchain in association with the first code comprising:

Storing the first code identification in association with the first code into the blockchain;

the second code identification is stored in the blockchain in association with a second code that is a duplicate of the first code.

8. The method of claim 5, further comprising:

receiving a fourth transaction for invoking the first contract;

acquiring the code identification and the value of the immutable variable from the state data of the first contract according to the fourth transaction;

reading the first code from the blockchain according to the code identification;

the first contract is executed based on the first code and the value of the immutable variable.

9. The method of claim 8, the fourth transaction invoking a first function of the first contract, the executing the first contract based on the first code and the value of the immutable variable comprising: and replacing the invariable variable in the first function with the value of the invariable variable to obtain a third code, and executing the third code.

10. A blockchain node comprising:

11. A blockchain node comprising a memory having executable code stored therein and a processor that, when executing the executable code, implements the method of any of claims 1-9.