Method for deploying a contract in a blockchain and blockchain node

Abstract

A method and a blockchain node for deploying a contract in a blockchain, the method comprising: receiving a first transaction for deploying a first contract, the first transaction invoking a second contract, incoming parameters of the second contract including a code identifier of a first code and a value of an immutable variable in the first code, the code identifier and the first code being pre-associatively stored in the blockchain, the first code including a first function, the first function including a fixed name and being used for initializing the contract, the second contract including a call to the first function; before executing the first function according to the call in the second contract, in a case where the second contract is a system contract, obtaining the first function in the first code according to the code identifier; and storing state data of the first contract in the blockchain by executing the first function, the state data of the first contract including the code identifier and the value of the immutable variable.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of blockchain technology, and in particular relate to a method for deploying contracts in a blockchain and a blockchain node. Background Technology

[0002] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. In a blockchain system, data blocks are sequentially linked together in a chain-like data structure, and a distributed ledger is cryptographically guaranteed to be immutable and unforgeable. Due to its decentralized, immutable, and autonomous characteristics, blockchain is receiving increasing attention and application. Summary of the Invention

[0003] The purpose of this invention is to provide a solution for deploying contracts in a blockchain, thereby reducing the resources required for contract deployment.

[0004] This specification provides, in a first aspect, a method for deploying a contract in a blockchain, executed by a blockchain node, the method comprising:

[0005] The system receives a first transaction for deploying a first contract. The first transaction calls a second contract. The input parameters to the second contract include a code identifier of a first code and the value of an immutable variable in the first code. The code identifier and the first code are pre-associated and stored in the blockchain. The first code includes a first function with a fixed name and is used to initialize the contract. The second contract includes a call to the first function.

[0006] Before executing the first function according to the call in the second contract, determine whether the second contract is a system contract;

[0007] If the second contract is determined to be a system contract, the first function in the first code is obtained according to the code identifier;

[0008] By executing the first function, the state data of the first contract is stored in the blockchain, and the state data of the first contract includes the code identifier and the value of the immutable variable.

[0009] The second aspect of this specification provides a blockchain node, including:

[0010] The receiving unit is used to receive a first transaction for deploying a first contract. The first transaction calls a second contract. The input parameters to the second contract include a code identifier of a first code and the value of an immutable variable in the first code. The code identifier and the first code are pre-associated and stored in the blockchain. The first code includes a first function with a fixed name and is used to initialize the contract. The second contract includes a call to the first function.

[0011] A determining unit is configured to determine whether the second contract is a system contract before executing the first function according to the call in the second contract;

[0012] The acquisition unit is configured to acquire the first function in the first code based on the code identifier when it is determined that the second contract is a system contract;

[0013] A storage unit is used to store the state data of the first contract in the blockchain by executing the first function. The state data of the first contract includes the code identifier and the value of the immutable variable.

[0014] A third aspect of this specification provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method described in the first aspect.

[0015] A fourth aspect of this specification provides a blockchain node, including a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to implement the method described in the first aspect.

[0016] In the scheme provided in the embodiments of this specification, the contract is deployed in two stages. The first stage is the code storage stage, where the initial code of the contract is first stored in the blockchain. In this initial code, immutable variables are not replaced with specific variable values, and the initial code includes an initialization function. The second stage is the contract deployment stage, where a transaction to deploy the contract is sent to the blockchain. This transaction calls the system contract, and the input parameters to the system contract include the identifier of the initial code and the values ​​of the immutable variables. The system contract calls the initialization function. In this stage, the blockchain nodes determine whether the transaction calls the system contract through a preset permission control protocol. The execution of the initialization function is only allowed if the transaction calls the system contract, thus deploying the contract in the blockchain. This ensures that the contract's state data includes the identifier of the initial code and the values ​​of the immutable variables. This setup reduces the overhead of user contract deployment and also reduces the storage resources required to store contract state data. Simultaneously, the permission control logic in the blockchain nodes ensures the security of contract deployment. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments in this specification, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a schematic diagram illustrating the deployment of a smart contract in one embodiment;

[0019] Figure 2 This is a schematic diagram illustrating the invocation of a smart contract in one embodiment;

[0020] Figure 3 This is a schematic diagram of a block storage structure in one embodiment;

[0021] Figure 4 This is a flowchart illustrating the method for storing the initial code of a contract in the embodiments of this specification;

[0022] Figure 5 This is a schematic diagram of the initial contract code in the embodiments of this specification;

[0023] Figure 6 This is a flowchart of the method for deploying contracts in the embodiments of this specification;

[0024] Figure 7 This is a schematic diagram illustrating the state storage of the contract in the embodiments of this specification;

[0025] Figure 8 This is a flowchart illustrating the method of calling the contract in the embodiments of this specification;

[0026] Figure 9 This is a structural diagram of a blockchain node in one of the embodiments of this specification. Detailed Implementation

[0027] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0028] Blockchains are generally classified into three types: public blockchains, private blockchains, and consortium blockchains. In addition, there are various combinations of these types, such as private blockchain + consortium blockchain, consortium blockchain + public blockchain, etc. Public blockchains offer the highest degree of decentralization. Ethereum is a prime example of a public blockchain. Participants can read data records on the chain, participate in transactions, and compete for the right to record new blocks. Furthermore, participants (represented by nodes on the blockchain) can freely join and leave the network and perform related operations. Private blockchains, on the other hand, have write permissions controlled by a specific organization or institution, and data read permissions are governed by organizational regulations. Simply put, a private blockchain can be a weakly centralized system with strictly limited and few participating nodes. This type of blockchain is more suitable for internal use within specific organizations. Consortium blockchains fall between public and private blockchains, achieving "partial decentralization." Each node in a consortium blockchain typically has a corresponding entity or organization; participants join the network through authorization and form a consortium of interested parties to jointly maintain the blockchain's operation.

[0029] Whether public, private, or consortium blockchains, most can provide smart contract functionality. A smart contract on a blockchain is a contract that can be triggered and executed by transactions on the blockchain system. Smart contracts can be defined in the form of code.

[0030] Taking Ethereum as an example, it allows users to create and invoke complex logic within the Ethereum network. At the core of Ethereum as a programmable blockchain is the Ethereum Virtual Machine (EVM), which can be run by every Ethereum node. The EVM is a Turing-complete virtual machine, meaning that various complex logics can be implemented using it. Users publish and invoke smart contracts in Ethereum, which run on the EVM. In fact, the virtual machine directly runs virtual machine code (virtual machine bytecode, hereinafter referred to as "bytecode"). Smart contracts deployed on the blockchain can be in the form of bytecode.

[0031] Figure 1 This is a schematic diagram illustrating the deployment of a smart contract in one embodiment. For example... Figure 1 As shown, after Bob sends a transaction containing information about creating a smart contract to the Ethereum network, Node 1's EVM can execute this transaction and generate the corresponding contract instance. In Figure 1, "0x6f8ae93…" represents the address of this contract. The transaction's data field can store bytecode, and the transaction's to field is an empty account. After the nodes reach a consensus through the consensus mechanism, the contract is successfully deployed, and users can subsequently call this contract.

[0032] After a contract is successfully deployed, a contract account corresponding to the smart contract appears on the blockchain, with a specific address. The contract code and account storage are stored in this contract account. The behavior of the smart contract is controlled by the contract code, while the smart contract's account storage preserves the contract's state. In other words, a smart contract enables the creation of a virtual account on the blockchain that contains both contract code and account storage.

[0033] As mentioned earlier, the `data` field of a transaction that creates a smart contract can include the smart contract's bytecode. Bytecode consists of a series of bytes, each byte representing an operation. For reasons of development efficiency and readability, developers can choose to write smart contract code in a high-level language instead of directly writing bytecode. The smart contract code written in a high-level language is compiled by a compiler to generate bytecode, which can then be deployed to the blockchain. Ethereum supports many high-level languages, such as Solidity, Serpent, and LLL.

[0034] Taking Solidity as an example, contracts written in it are very similar to classes in object-oriented programming languages. A contract can declare various members (or objects), including state variables, functions, function modifiers, events, etc. State variables are values ​​stored in the smart contract's account store and are used to save the contract's state.

[0035] The following is a simple code example 1 of a smart contract written in the Solidity language:

[0036]

[0037] Code Example 1. SimpleStorage Code

[0038] In code example 1 above, line 2 declares a string-type state variable `storedData`, and line 3 declares an event that stores the address of the initiator who called the contract and the string `s`. Lines 4-7 define a `set` function, which takes the string `s` as its input parameter. The `set` function performs the following operations: sets the input parameter to the state variable `storedData` and generates an event whose content includes the address of the initiator who called the contract and the string `s`.

[0039] As mentioned earlier, the state variables will ultimately be stored in the database. The generated events generally take the following form:

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

[0041] Here, the first topic, topic1, is generally a default value, such as an identifier for the receipt, which could be a hash value obtained by concatenating the event name, event parameter types, etc. The existence of each topic (topic2 to topicn) depends on whether the parameter was modified with the `Indexed` modifier. If it was, the value of that parameter would be a topic in the receipt; otherwise, it would generally be placed in the `data`. In the example code 1 above, when declaring the event in line 3, neither of the two parameters, `address from` and `s`, is modified with the `Indexed` modifier, so they would generally be placed in the `data`. The code in line 6 sets the `data` content of the event [msg.sender, s] using the `stored()` event. Thus, the overall form of the event operated on in line 6 is:

[0042] [topic1: Event identifier][data: msg.sender, s]

[0043] Lines 8-10 define the `get` function. This function returns the value of the queried `storedData`. `returns (string)` indicates the type of the return value, and the `constant` modifier indicates that this function cannot modify the values ​​of state variables in the contract.

[0044] In addition, such as Figure 2 As shown, still using Ethereum as an example, after Bob sends a transaction containing information about calling a smart contract to the Ethereum network, the EVM of node 1 can execute this transaction and generate the corresponding contract instance. In Figure 2, the `from` field of the transaction is the address of the account initiating the smart contract call, and "0x6f8ae93…" in the `to` field represents the address of the smart contract being called. The `data` field of the transaction stores the method and parameters for calling the smart contract. After calling the smart contract, the value of `storedData` may change. Subsequently, a client can access the transaction through a blockchain node (e.g., Figure 2 Node 6) View the current value of storedData.

[0045] Smart contracts can be executed independently on each node of the blockchain network in a prescribed manner. All execution records and data are stored on the blockchain. Therefore, when such a transaction is completed, the blockchain stores an immutable and unlost transaction certificate.

[0046] As mentioned earlier, `storedData` in the example above is the state variable, which is stored in the smart contract's account storage. In various blockchain networks that introduce smart contracts, taking Ethereum as an example, accounts typically include two types:

[0047] Contract account: Stores the executed smart contract code and the values ​​of the state within the smart contract code; it can typically only be activated by an external account.

[0048] Externally owned account: The user's account.

[0049] The design of external and contract accounts is essentially a mapping from account addresses to account states. Account states typically include fields such as Nonce, Balance, Storage root, and CodeHash. Nonce and Balance exist in both external and contract accounts. CodeHash and Storage root attributes are generally only valid for contract accounts.

[0050] Nonce: A counter. For external accounts, this number can represent the number of transactions sent from the account address; for contract accounts, it can be the number of contracts created by the account.

[0051] Balance: Account balance.

[0052] Storage root: The hash of the root node of an MPT tree that organizes the storage of state variables for contract accounts.

[0053] CodeHash: The hash value of the smart contract code. For contract accounts, this is the hash value of the smart contract; for external accounts, since the smart contract is not included, the CodeHash field can generally be an empty string or a string of all zeros.

[0054] MPT stands for Merkle Patricia Tree, a tree structure that combines the features of a Merkle Tree and a Patricia Tree (a compressed prefix tree, a more space-efficient Trie tree, also known as a dictionary tree). The Merkle Tree algorithm calculates a hash value for each transaction, then joins each pair of transactions and calculates the hash again, continuing until the top-level Merkle root. Ethereum uses an improved MPT tree, such as a 16-ary tree structure, which is often simply referred to as an MPT tree.

[0055] The Ethereum MPT tree data structure includes a state trie. The state trie contains key-value pairs (kv) representing the storage content for each account in the Ethereum network. The "key" in the state trie can be a 160-bit identifier (such as the address of an Ethereum account or part of its hash value, hereinafter referred to as the account address), distributed across storage from the root node to the leaf nodes of the state trie. The "values" in the state trie are generated by encoding the information of the Ethereum account using recursive-length prefix encoding (RLP). As mentioned earlier, for external accounts, the values ​​include nonce and balance; for contract accounts, the values ​​include nonce, balance, codehash, and storageroot.

[0056] A contract account is used to store the state of a smart contract. Once a smart contract is deployed on the blockchain, a corresponding contract account is created. This contract account typically has several states defined by state variables within the smart contract, which generate new values ​​when the smart contract executes. A smart contract usually refers to a contract defined in code within a blockchain environment that can automatically execute its terms. Once an event triggers a term in the contract (meeting the execution conditions), the code can execute automatically. In the blockchain, the contract's state is stored in a storage trie. The hash value of the storage trie's root node is stored in the aforementioned storage root, thus locking all the contract's states to this contract account through hashing. The storage trie is also an MPT tree structure, storing a key-value mapping from state addresses to state values. Information from the root node to the leaf node of the storage trie tree is arranged sequentially to store the address of a state, and the leaf node stores the state's value.

[0057] Figure 3 This is a schematic diagram of a blockchain data storage structure. For example... Figure 3As shown, each block's header includes several fields, such as the previous block hash (prev Hash in the diagram), a nonce number, a timestamp, a block number (Block Num), a state root hash (State_Root), a transaction root hash (Transaction_Root), and a receipt root hash (Receipt_Root). The Prev Hash in the 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 blockchain achieves locking of the previous block by the next block through the block header. Specifically, State_Root, Transaction_Root, and Receipt_Root lock the state set, transaction set, and receipt set, respectively. The state set, transaction set, and receipt set are organized in a tree structure. Generally, they can be the same tree structure or different tree structures. For example, Ethereum uses the same MPT structure. In some tree structures like Ethereum, which include sets of smart contract states, there is a two-level MPT structure: the leaf nodes of the upper-level MPT structure include two types of external accounts and contract accounts; each contract account includes the lower-level MPT structure, and the leaf nodes of the lower-level structure include the values ​​of the state in the contract account.

[0058] Taking Ethereum as an example again, we can combine Figure 3As shown, `state_root` is the hash value of the root of the MPT tree composed of the states of all accounts in the current block. In other words, pointing to `state_root` is an MPT-style state trie. The root node of this MPT tree is generally an extension node or a branch node, and `state_root` typically stores the hash value of this root node. The root node can be connected to one or more extension nodes / branch nodes below it; these multiple levels of tree nodes can be collectively called internal nodes. A portion of the values ​​from each node from the root node to the leaf node in this MPT can be concatenated sequentially to form an account address as the key. The account information stored in the leaf node is the value corresponding to this account address, thus forming a key-value pair. This key can also be a portion of the hash value of the account address (using a hash algorithm such as SHA3), and its stored value can be an rlp (Account), i.e., the rlp encoding of the account information. The account information consists of a four-tuple of [nonce, balance, storage root, codeHash]. As mentioned earlier, external accounts typically only have the nonce and balance fields, while the storage root and codeHash fields default to storing empty strings or strings of all zeros. This means that external accounts do not store contracts or the state variables generated after contract execution. Contract accounts generally include Nonce, Balance, Storage root, and CodeHash. Nonce is the transaction counter for the contract account; Balance is the account balance; Storage root corresponds to another MPT, which links to contract-related state information; and CodeHash is the hash value of the contract code. Whether external or contract accounts, their account information is generally located in a single leaf node. The path from the root node's Extension Node / Branch Node to each account's Leaf Node may involve several branch nodes and extension nodes.

[0059] The state trie can be an MPT-style tree, typically a 16-ary tree, meaning each level can have a maximum of 16 child nodes. An Extension Node, used to store a common prefix, typically has one child node, which can be a Branch Node. A Branch Node can have a maximum of 16 child nodes, potentially including Extension Nodes and / or Leaf Nodes.

[0060] For a contract account within the state trie, its `storage_root` points to another tree, also in MPT form, which stores data related to the contract's execution state variables. This `storage_root` points to an MPT-form tree called the Storage Trie, specifically the hash value of the root node. Generally, this Storage Trie also stores key-value pairs. The key represents the address of the state variable, and its value can be the result of processing the state variable's declaration location (counting from 0) according to certain rules, such as SHA3 (state variable declaration location) or SHA3 (contract name + state variable declaration location). The value stores the state variable's value (e.g., an RLP-encoded value). A portion of the data stored along the path from the root node through intermediate nodes to the leaf node forms the key, and the leaf node stores the value. As mentioned earlier, this Storage Trie can also be an MPT-form tree, typically a 16-ary tree, meaning that a Branch Node can have a maximum of 16 child nodes, which may include Extension Nodes and / or Leaf Nodes. An ExtensionNode typically has one child node, which can be a Branch Node or a Leaf Node.

[0061] For example Figure 3The Leaf Node Account P in the state trie is a contract account whose Storage Root locks all the states stored in that contract. These states are organized as an MPT tree, with a tree structure like the Storage trie linked by the Storage Root. In this linked Storage trie, taking Leaf Node StateVariable N as an example, if it is the value of storedData from the aforementioned contract code example, then its key can be, but is not limited to, sha3 (the declaration location of storedData), and its value is s (for simplicity, the encoding format of the value is omitted here, such as RLP, and similarly, will not be elaborated further). The key values ​​are distributed sequentially from the root node to the leaf node (i.e., Leaf Node Variable N) of the storage trie.

[0062] As mentioned above, after a transaction for creating a smart contract is sent to the blockchain, and consensus is reached on the transaction, each node on the blockchain can execute it. At this point, a contract account corresponding to the smart contract appears on the blockchain (including, for example, an account identifier (Identity), a contract hash value (Codehash), and a contract storage root (StorageRoot), and has a specific address. The contract code and account storage can be stored in the contract account's storage. The behavior of the smart contract is controlled by the contract code, while the smart contract's account storage preserves the contract's state. In other words, the smart contract creates a virtual account on the blockchain containing contract code and account storage. For contract deployment or contract update transactions, the Codehash value will be generated or changed. Subsequently, blockchain nodes can receive transaction requests to invoke the deployed smart contract. This transaction request can include the address of the invoked contract, the functions within the invoked contract, and the input parameters. Generally, after consensus is reached on this transaction request, each node on the blockchain can independently execute the specified invoked smart contract.

[0063] In a deployed contract, the root StorageRoot can be a default value or a hash value calculated from the root node of the underlying Storage Trie. This generally depends on whether the deployed contract performs initialization operations, such as executing an initialization function. If the deployed contract includes an initialization function, it typically involves initializing state variables that will eventually be stored in the underlying database; this initialization can be performed by the virtual machine. After initialization, as described above, the state variables can be used to construct an MPT tree, thus obtaining the root node of this MPT tree and its hash value. If the deployed contract does not include an initialization function, the blockchain platform can assign a default value to StorageRoot, such as the hash value of empty content, instead of executing the function.

[0064] Once deployed, the contract, as mentioned earlier, can be invoked subsequently. Figure 2 As shown, after Bob initiates a transaction to call a smart contract on the Ethereum network, the contract executes, thus setting the state variable to the string "hello". For example... Figure 2 A transaction invoking a contract is sent to the blockchain network, and after consensus is reached, each node can execute the transaction. The `to` field of the transaction indicates the address of the contract being invoked. Any node can locate the contract account's storage based on the contract's address, and then read the Codehash from the contract account's storage, thereby finding the corresponding contract bytecode. The node can then load the contract bytecode from storage into the virtual machine to execute the contract.

[0065] Ethereum also supports including immutable variables in contracts. The values ​​of immutable variables in a contract are set during contract deployment and cannot be changed after deployment. When the virtual machine executes the transaction used to deploy the contract, it can determine the values ​​of immutable variables in the contract code through instructions in the initialization function. These instructions, for example, specify the input parameters to the initialization function, allowing the virtual machine to determine the values ​​of the immutable variables as the input parameters. Specifically, when executing the transaction used to deploy the contract, the virtual machine executes the initialization function in the contract code, replacing the immutable variables in other functions of the contract with the values ​​indicated in the initialization function (e.g., input parameters), and storing this updated code of other functions as contract code on the blockchain. This means that if two contracts use the same bytecode before deployment but set different values ​​for immutable variables, the contract code deployed to the blockchain will be different.

[0066] For contracts containing immutable variables, this specification's embodiments deploy the contract in two phases. The first phase is the code storage phase, where the initial code of the contract is stored in the blockchain, in which the immutable variables are not replaced with specific variable values. The second phase is the contract deployment phase, where a contract deployment transaction is sent to the blockchain. This transaction includes the identifier of the initial code and the values ​​of the immutable variables. By executing this transaction, the contract is deployed in the blockchain, ensuring that the contract's state data includes the identifier of the initial code and the values ​​of the immutable variables. This setup reduces the overhead of contract deployment for users and also reduces the storage resources required to store contract state data.

[0067] Figure 4 This is a flowchart illustrating the method for storing the initial code of a contract in an embodiment of this specification. This method can be executed by any blockchain node.

[0068] like Figure 4 As shown, in S410, the blockchain node receives transaction Tx1 for storing the initial code of the contract. Transaction Tx1 calls the system contract, and the input parameters to the system contract include the initial code of the contract and the code identifier of the initial code of the contract.

[0069] To deploy a contract, the deployer can first execute the first phase described above, which involves sending a transaction Tx1 to the blockchain to store the initial contract code, ensuring that all nodes on the blockchain can receive this transaction Tx1. Alternatively, the initial code publisher can execute the first phase by sending transaction Tx1 to the blockchain. After sending transaction Tx1 and storing the initial code on the blockchain, the initial code publisher can publish the initial code and its identifier on a specific publishing platform, allowing the contract deployer to deploy the contract based on this identifier according to their needs.

[0070] As mentioned above, the initial code of the contract includes an identifier for an immutable variable, but does not replace this immutable variable with a specific variable value. Specifically, Figure 5 This is a schematic diagram of the initial contract code in the embodiments of this specification. Figure 5 As shown, the initial code of this contract includes, for example, an initialization function Init (i.e., the code for the Init function), a function method1, and a function method2. Function method1 and / or function method2 include identifiers for one or more immutable variables, such as the immutable variable immut1.

[0071] A system contract is pre-deployed in the blockchain. This system contract can be used to store initial contract code, deploy contracts, etc. In one implementation, the system contract can be deployed in the genesis block. Transaction Tx1 can call the function Storage() in the system contract, which stores the initial contract code, and pass the initial contract code and its identifier as parameters to the function. In one implementation, the identifier of the initial contract code can be the code hash value of the initial contract code. In another implementation, the identifier of the initial contract code can be an easily identifiable string, such as "code1". By setting the identifier of the initial contract code in this way, two sets of initial contract code with different identifiers but the same code can be stored in the blockchain. For example, two identical initial codes can be stored with "code1" and "code2" as identifiers respectively, which facilitates different updates or upgrades to these two sets of initial code.

[0072] Specifically, in one implementation, transaction Tx1 takes the following form:

[0073] {Transaction Tx1

[0074] From: Alice(0xf53…)

[0075] To:SystemContract

[0076] Data:{storage();code1,"code1"}

[0077] }

[0078] Here, we assume that SystemContract represents the contract address of the system contract, storage() is the function in the system contract used to store the initial code of the contract, code1 is the initial code of contract1, and "code1" is the code identifier of code1.

[0079] In S420, based on transaction Tx1, blockchain nodes associate the initial code of the contract and its code identifier with the state data of the system contract.

[0080] After consensus is reached on transaction Tx1 in a blockchain, each node in the blockchain executes transaction Tx1. After completing the execution of transaction Tx1, each blockchain node stores the initial code of the contract and its code identifier in the state data of the system contract based on the execution result of transaction Tx1.

[0081] By associating the initial code of the storage contract with its code identifier, the initial code of the contract stored in the blockchain can be read based on the code identifier.

[0082] Specifically, transaction Tx1 includes a code identifier "code1". After the blockchain node completes the execution of transaction Tx1, it associates and stores the code code1 with the code identifier "code1" in the contract state of the system contract.

[0083] After completing the first phase described above, the contract deployer can deploy the contract through the second phase described above.

[0084] Figure 6 This is a flowchart illustrating the method for deploying a contract as described in the embodiments of this specification. This method can be executed by any blockchain node in the blockchain.

[0085] refer to Figure 6 In S610, the blockchain node receives transaction Tx2 for deploying a contract. Transaction Tx2 calls the system contract. The input parameters to the system contract include the code identifier of the initial code of contract Contract1 and the values ​​of immutable variables in the initial code. The system contract includes a call to the initialization function.

[0086] As described above, the contract is deployed in a two-stage manner in the embodiments of this specification. Therefore, when deploying the contract, the initial code of the contract has already been stored in the blockchain. The contract deployer only needs to obtain the code identifier of the initial code corresponding to the contract to be deployed to deploy the contract, without needing to include the contract code in the contract deployment transaction.

[0087] For example, transaction Tx2 includes the following forms:

[0088] {Transaction Tx2

[0089] From: Bob(0xf53…)

[0090] To: SystemContract

[0091] Data:{ deploy();“code1”;immut1=V1}

[0092] }

[0093] In this system contract, `deploy()` is the function used to deploy contracts. "code1" is the code identifier of the initial code `code1` corresponding to the contract to be deployed, `immut1` is the identifier of the immutable variable in the initial code `code1`, and `V1` is the value of the immutable variable `immut1`. In one implementation, the input parameters to the `deploy()` function in transaction `Tx2` also include the contract address of the contract to be deployed. This contract address is generated by the contract deployer and included as an input parameter in transaction `Tx2`. The `deploy()` function includes a call to an initialization function. In the embodiments of this specification, the name of the initialization function in the initial code of each contract is set to a fixed name, such as `Init()`. Therefore, by including a call to the `Init()` function in the `deploy()` function, when a user calls the `deploy()` function to deploy any contract, the `Init()` function in that specific initial code can be called based on the code identifier of the initial code in the input parameters.

[0094] In other words, with Figure 1 The transaction shown for deploying the contract differs in that it does not include the contract code itself, but instead includes the code identifier "code1" of the initial contract code and the value V1 of the immutable variable immut1 within the initial code. In this way, the data volume of transaction Tx2 is significantly reduced compared to... Figure 1 The amount of transaction data is significantly reduced, thereby reducing the communication bandwidth resources used for broadcasting transactions (Tx2) on the blockchain and the computing resources spent by blockchain nodes to verify transaction signatures. Furthermore, from the user's perspective, contract deployers typically need to spend blockchain resources (such as gas in Ethereum) to send transactions to the blockchain, and the amount of gas spent is positively correlated with the amount of transaction data sent. By reducing the amount of transaction data, the overhead for blockchain users is greatly reduced.

[0095] It is understood that the above-described form of transaction Tx2 is only an example, and the transactions used to deploy contracts in the embodiments of this specification are not limited to this. For example, in one case, the Init function in the initial code of the contract can set the value of the immutable variable to be equal to the value of the transaction sender (i.e., the from field), so that no additional value needs to be assigned to the immutable variable in the transaction of deploying the contract.

[0096] In S620, before executing the initialization function in the initial code according to the call to the initialization function of the system contract, it is determined whether the first transaction calls the system contract.

[0097] After consensus is reached on transaction Tx2 within the blockchain, blockchain nodes can execute transaction Tx2. Specifically, based on transaction Tx2's call to the `deploy` function in the system contract, the blockchain node obtains the system contract code, retrieves the `deploy` function from the system contract code, and begins executing the `deploy` function. When the blockchain node reaches a call to the initialization function `Init` during the execution of `deploy`, before executing `Init` according to this call, the blockchain node first determines whether transaction Tx2 has called the system contract based on the blockchain platform's platform code. This platform code embodies the blockchain platform's platform protocol. Specifically, the blockchain node reads the contract address in the `To` field of transaction Tx2 and determines whether this contract address matches the preset system contract address. If they match, it can be determined that transaction Tx2 has called the system contract; if they do not match, it can be determined that transaction Tx2 has not called the system contract.

[0098] In a consistent scenario, blockchain nodes execute... Figure 6 S630 in this context refers to the process where, during transaction execution, each time a blockchain node encounters a call to the `Init` function, it first checks whether the transaction invokes a system contract before executing `Init`. If the transaction does not invoke a system contract, execution is terminated, and the transaction is considered a failure. This process allows the blockchain node to control access to contract deployment, ensuring that only system contracts are allowed to call the `Init` function to deploy contracts. By ensuring that only system contracts can call the `Init` function, other contracts are prevented from resetting the state data of deployed contracts, thus improving the security of contract deployment.

[0099] When transaction Tx2 includes the contract address generated by the deployer of contract Contract1, the system contract can have pre-defined code to determine whether the contract address has already been deployed. Specifically, the blockchain node uses this pre-defined code to determine whether the state database contains the state data corresponding to the contract address. If it does, the contract address has been deployed, and the blockchain node terminates the execution of the transaction, indicating a transaction failure. If the state database does not contain the state data corresponding to the contract address, the contract address has not been deployed, and the blockchain node continues to execute subsequent steps S630. This pre-defined code in the system contract ensures that the `Init` function is called only during contract initialization (i.e., before the contract address is deployed to the blockchain), guaranteeing that the contract initialization function is called only once during the contract's lifecycle. This prevents the reset of the deployed contract's state data and improves the security of contract deployment.

[0100] In S630, when a blockchain node determines that transaction Tx2 calls the system contract, it obtains the initialization function Init() in the initial code of contract Contract1 based on the code identifier in transaction Tx2.

[0101] When a blockchain node determines that transaction Tx2 calls a system contract, or when a blockchain node determines that transaction Tx2 calls a system contract and the contract address in transaction Tx2 has not been deployed, it can read the initial code corresponding to the code identifier "code1" from the contract state of the system contract based on the code identifier in transaction Tx2, and then read the initialization function Init() from the initial code.

[0102] In S640, after reading the initialization function, the blockchain node executes the initialization function to store the state data of Contract1 in the blockchain. This state data includes code identifiers and values ​​of immutable variables.

[0103] In the case where the contract address is not included in the input parameters of the deploy function in transaction Tx2, the blockchain node executes the initialization function Init to generate the contract address corresponding to contract Contract1. Based on the contract address corresponding to contract Contract1, a leaf node corresponding to the contract address is added to the state tree above, and the state data (or state storage) of contract Contract1 is stored in the leaf node.

[0104] In transaction Tx2, when the `deploy` function receives a contract address as an input parameter, the blockchain node executes the initialization function `Init`. Based on the contract address corresponding to `Contract1`, it adds a leaf node corresponding to that contract address in the aforementioned state tree, storing the state data of `Contract1` within that leaf node. Specifically, the `Init` function can call the write interface provided by the blockchain platform to write each field of the state data into the leaf node corresponding to `Contract1`.

[0105] Figure 6 This is a schematic diagram illustrating the state storage of the contract in the embodiments of this specification. For example... Figure 6 As shown, the state storage of Contract Conetract1 generated from transaction Tx2 may include the following fields: Nonce, balance, Storage hash, Ref, and Immut. Among these, the Nonce, balance, and Storage hash fields are related to... Figure 3 The same fields are shown in the contract state storage, and will not be repeated here. Figure 3Unlike other contract state stores, Contract1's state store includes a Ref field and an Immut field. The Ref field identifies the contract code referenced by Contract1 (e.g., "code1"), and the Immut field contains the values ​​(e.g., V1) of immutable variables (e.g., Immut1) within Contract1. Furthermore, Contract1's state store does not include a code hash field. This means that Contract1 does not store its own code during deployment, therefore, its state store does not need to include the code hash value.

[0106] like Figure 6 As shown, contract deployers can also deploy contracts Contract2 and Contract3, which reference code1, in the blockchain in the same way. That is, the Ref field in both Contract2 and Contract3 is code1, indicating that Contract1-Contract3 reference the same initial contract code, but the values ​​of immutable variables in Contract1-Contract3 are different. Figure 6 As can be seen from the embodiments of this specification, in the case of deploying multiple contracts that reference the same initial contract code, only one initial contract code needs to be stored, instead of storing multiple final codes corresponding to the initial code (the final code is the code obtained by replacing the immutable variables in the initial code with variable values), thereby reducing the amount of data that needs to be stored and saving storage resources.

[0107] Understandable. Figure 6 The contract state storage shown is suitable for contracts that require setting immutable variable values, while contracts that do not require setting immutable variable values ​​can continue to use [the following method / method]: Figure 3 The state storage is shown.

[0108] Figure 8 This is a flowchart illustrating the method for invoking a contract in an embodiment of this specification. This method is applicable to systems with, for example, contracts... Figure 6 The state storage contract shown below is described using Contract1 as an example.

[0109] like Figure 8 As shown, in S810, a transaction for invoking the contract is received.

[0110] When a blockchain user (such as Bob) wants to invoke contract Contract1, they can send a transaction Tx3 to the blockchain to invoke contract Contract1. For example, transaction Tx3 includes the form described below:

[0111] {Transaction Tx3

[0112] From: Bob(0xf53…)

[0113] To:Contract1

[0114] Data:{method1;arg}}

[0115] Specifically, transaction Tx3 calls function method1 in contract Contract1, and... Figure 2 Similarly, in the transaction that calls the contract shown, the From field of transaction Tx3 is Bob, the To field is the contract address of contract Contract1, the Data field is the function name of function method1, and the input parameter (arg) to function method1.

[0116] After user Bob sends transaction Tx3 to the blockchain, the blockchain broadcasts transaction Tx3 so that every blockchain node can receive transaction Tx3 and execute it.

[0117] In S820, blockchain nodes read the state data of Contract1 based on transactions. This state data includes code identifiers and values ​​of immutable variables, as described above.

[0118] When a blockchain node executes transaction Tx3, it reads the state data of contract Contract1 from the blockchain's state database based on the contract address of contract Contract1 in transaction Tx3, i.e. Figure 6 The state storage of Contract1 shown is as follows: Figure 6 As shown, the state storage of Contract1 includes the code identifier "Ref=code1" and the value of the immutable variable "Immut1=V1".

[0119] In S830, blockchain nodes read the initial contract code from the blockchain based on the code identifier.

[0120] After obtaining the code identifier "code1" of Contract1, a blockchain node can read the initial contract code corresponding to "code1" from the blockchain based on this code identifier. This initial contract code is, for example, stored in the contract state of a system contract. The blockchain node can read the contract state of the system contract based on a pre-set contract address, and then read the code associated with the code identifier "code1" from that contract state. This code is the initial contract code of Contract1.

[0121] In S840, Contract1 is executed based on the initial code of Contract1 and the values ​​of immutable variables.

[0122] After obtaining the initial code of Contract1, the blockchain node replaces the immutable variables in the initial code with the values ​​of the immutable variables in the state storage of Contract1, thereby obtaining the final code of Contract1. The blockchain node can then execute Contract1 based on this final code.

[0123] Specifically, based on the call to function method1 in transaction Tx3, the blockchain node can obtain the initial code of function method1 from the initial code, replace the immutable variables (such as Immut1) in the initial code of function method1 with the value V1 of Immut1 in the state storage, and obtain the final code of function method1. Then, the blockchain node can substitute the input parameters in transaction Tx3 to execute the final code of function method1, thereby completing the execution of transaction Tx3.

[0124] Figure 9 This is a structural diagram of a blockchain node in one of the embodiments of this specification, including:

[0125] The receiving unit 91 is used to receive a first transaction for deploying a first contract. The first transaction calls a second contract. The input parameters to the second contract include a code identifier of a first code and the value of an immutable variable in the first code. The code identifier and the first code are pre-associated and stored in the blockchain. The first code includes a first function. The first function has a fixed name and is used to initialize the contract. The second contract includes a call to the first function.

[0126] Determining unit 92 is configured to determine whether the second contract is a system contract before executing the first function according to the call in the second contract;

[0127] Acquisition unit 93 is used to acquire a first function in the first code based on the code identifier when it is determined that the second contract is a system contract;

[0128] Storage unit 94 is used to store the state data of the first contract in the blockchain by executing the first function. The state data of the first contract includes the code identifier and the value of the immutable variable.

[0129] This specification also provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform actions such as... Figure 4 , Figure 6or Figure 8 The method shown.

[0130] This specification also provides a blockchain node, including a memory and a processor. The memory stores executable code, and when the processor executes the executable code, it implements... Figure 4 , Figure 6 or Figure 8 The method shown.

[0131] In the solution provided in the embodiments of this specification, the contract is deployed in two stages. The first stage is the code storage stage, where the initial code of the contract is first stored in the blockchain. In this initial code, immutable variables are not replaced with specific variable values, and the initial code includes an initialization function. The second stage is the contract deployment stage, where a transaction to deploy the contract is sent to the blockchain. This transaction calls the system contract, and the input parameters to the system contract include the identifier of the initial code and the values ​​of the immutable variables. The system contract calls the initialization function, thereby deploying the contract in the blockchain by executing the initialization function, ensuring that the contract's state data includes the identifier of the initial code and the values ​​of the immutable variables. This setup reduces the overhead of user contract deployment and also reduces the storage resources required to store contract state data. Simultaneously, the access control logic in the blockchain nodes ensures the security of contract deployment.

[0132] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, 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, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0133] The controller can be implemented in any suitable manner. For example, it can take the form of 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 (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0134] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude the possibility that, with the future development of computer technology, the computer implementing the functions of the above embodiments may be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interaction device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices. Although one or more embodiments of this specification provide the method operation steps as described in the embodiments or flowcharts, more or fewer operation steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one of many possible execution orders and does not represent a unique execution order. In actual device or terminal product execution, the methods shown in the embodiments or drawings can be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitation, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes said elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0135] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0136] This 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 block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0137] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The functions specified in one or more boxes. 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, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0138] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory. Memory may include non-persistent storage in computer-readable media, random access memory (RAM), and / or non-volatile memory such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media. Computer-readable media includes both permanent and non-persistent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information that can be accessed by the computing device. As defined in this article, computer-readable media do not include transient media, such as modulated data signals and carrier waves.

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

[0140] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In a distributed computing environment, program modules can reside in local and remote computer storage media, including storage devices.

[0141] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

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

Claims

1. A method for deploying a contract in a blockchain, executed by a blockchain node, the method comprising: The system receives a first transaction for deploying a first contract. The first transaction calls a second contract. The input parameters to the second contract include a code identifier of a first code and the value of an immutable variable in the first code. The code identifier and the first code are pre-associated and stored in the blockchain. The first code includes a first function with a fixed name and is used to initialize the contract. The second contract includes a call to the first function. Before executing the first function according to the call in the second contract, determine whether the second contract is a system contract; If the second contract is determined to be a system contract, the first function in the first code is obtained according to the code identifier; By executing the first function, the state data of the first contract is stored in the blockchain, and the state data of the first contract includes the code identifier and the value of the immutable variable.

2. The method according to claim 1, further comprising: If it is determined that the second contract is not a system contract, the execution of the first transaction is deemed to have failed.

3. The method according to claim 1, wherein, The input parameters for the second contract also include the first contract address of the first contract. The step of storing the state data of the first contract in the blockchain by executing the first function includes: determining whether the state database includes state data corresponding to the first contract address by executing the first function; if the state database does not include state data corresponding to the first contract address, storing the state data of the first contract in association with the first contract address in the state database.

4. The method according to claim 1, wherein the state data of the first contract includes a first field for storing the code identifier.

5. The method according to claim 1, wherein the state data of the first contract includes a second field for storing the value of the immutable variable.

6. The method according to claim 1, further comprising: Receive a second transaction for storing the first code, the second transaction invoking the system contract, the input parameters to the system contract including the code identifier and the first code; According to the second transaction, the code identifier is stored in the state data of the system contract in association with the first code.

7. The method according to claim 6, further comprising: Receive a third transaction for updating the first code, the third transaction invoking the system contract, the input parameters of the system contract including the updated first code; The updated first code is stored in the state data of the system contract according to the third transaction.

8. The method according to claim 5, further comprising: Receive the fourth transaction used to invoke the first contract; Based on the fourth transaction, the code identifier and the value of the immutable variable are obtained from the state data of the first contract; The first code is read from the blockchain according to the code identifier; The first contract is executed based on the first code and the value of the immutable variable.

9. The method according to claim 8, wherein the fourth transaction calls the first function of the first contract, and the execution of the first contract based on the first code and the value of the immutable variable comprises: The immutable variable in the first function is replaced with the value of the immutable variable to obtain the third code, and the third code is executed.

10. A blockchain node, comprising: The receiving unit is used to receive a first transaction for deploying a first contract. The first transaction calls a second contract. The input parameters to the second contract include a code identifier of a first code and the value of an immutable variable in the first code. The code identifier and the first code are pre-associated and stored in the blockchain. The first code includes a first function with a fixed name and is used to initialize the contract. The second contract includes a call to the first function. A determining unit is configured to determine whether the second contract is a system contract before executing the first function according to the call in the second contract; The acquisition unit is configured to acquire the first function in the first code based on the code identifier when it is determined that the second contract is a system contract; A storage unit is used to store the state data of the first contract in the blockchain by executing the first function. The state data of the first contract includes the code identifier and the value of the immutable variable.

11. A blockchain node comprising a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method of any one of claims 1-9.

Images