WO2022148390A1 - 一种在区块链中部署、更新、调用智能合约的方法 - Google Patents

一种在区块链中部署、更新、调用智能合约的方法 Download PDF

Info

Publication number
WO2022148390A1
WO2022148390A1 PCT/CN2022/070464 CN2022070464W WO2022148390A1 WO 2022148390 A1 WO2022148390 A1 WO 2022148390A1 CN 2022070464 W CN2022070464 W CN 2022070464W WO 2022148390 A1 WO2022148390 A1 WO 2022148390A1
Authority
WO
WIPO (PCT)
Prior art keywords
contract
smart contract
account
compressed
code
Prior art date
Application number
PCT/CN2022/070464
Other languages
English (en)
French (fr)
Inventor
郭学鹏
闫莺
Original Assignee
支付宝(杭州)信息技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 支付宝(杭州)信息技术有限公司 filed Critical 支付宝(杭州)信息技术有限公司
Publication of WO2022148390A1 publication Critical patent/WO2022148390A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3827—Use of message hashing

Definitions

  • This specification relates to the field of information technology, in particular to a method for deploying, updating, and invoking smart contracts in the blockchain.
  • Smart contracts are distributed and stored in the blockchain network.
  • the volume (storage size) of the smart contract code increases or the number increases, the persistent storage of smart contracts in the blockchain will consume a lot of storage space, resulting in an increase in storage costs.
  • One of the embodiments of this specification provides a method for deploying a smart contract in a blockchain.
  • the method includes: receiving a transaction for deploying a smart contract, the transaction including one or more compressed machine codes of the smart contract; creating an account and an account address for the smart contract, and creating an account and an account address in the smart contract.
  • the one or more compressed machine codes are stored in the account.
  • One of the embodiments of this specification provides an apparatus for deploying a smart contract in a blockchain.
  • the apparatus includes a processor and a storage device, where the storage device is used for storing instructions, and when the processor executes the instructions, the method for deploying a smart contract in a blockchain as described in any embodiment of this specification is implemented.
  • the system includes a first transaction receiving module and a contract deployment module.
  • the first transaction receiving module receives a transaction for deploying a smart contract, the transaction including one or more compressed machine codes of the smart contract.
  • the contract deployment module is used to create an account and an account address of the smart contract, and store the one or more compressed machine codes in the account of the smart contract.
  • One of the embodiments of this specification provides a method for updating a smart contract in a blockchain.
  • the method includes: receiving a transaction for updating a smart contract, the transaction including an account address of the smart contract and one or more compressed machine codes of the smart contract; The one or more compressed machine codes are stored in the account of the smart contract.
  • One of the embodiments of this specification provides an apparatus for updating a smart contract in a blockchain.
  • the apparatus includes a processor and a storage device, the storage device is used to store instructions, and when the processor executes the instructions, the method for updating a smart contract in a blockchain as described in any embodiment of this specification is implemented .
  • the system includes a second transaction receiving module and a contract updating module.
  • the second transaction receiving module is configured to receive a transaction for updating the smart contract, and the transaction includes the account address of the smart contract and one or more compressed machine codes of the smart contract.
  • the contract update module is configured to store the one or more compressed machine codes in the account of the smart contract according to the account address of the smart contract.
  • One of the embodiments of this specification provides a method for invoking a smart contract in a blockchain.
  • the method includes: receiving a transaction calling a smart contract, the transaction including an account address of the smart contract; reading the compressed target machine code of the smart contract from the account of the smart contract according to the account address ; Decompress the compressed target machine code, and execute the obtained decompressed target machine code.
  • the system includes a third transaction receiving module, a contract code reading module and a contract execution module.
  • the third transaction receiving module is configured to receive a transaction calling a smart contract, and the transaction includes an account address of the smart contract.
  • the contract code reading module is configured to read the compressed target machine code of the smart contract from the account of the smart contract according to the account address.
  • the contract execution module is configured to decompress the compressed target machine code, and execute the obtained decompressed target machine code.
  • One of the embodiments of this specification provides a method for invoking a smart contract in a blockchain.
  • the method includes, in the process of executing the code of the first smart contract: determining the account address of the second smart contract from the statement calling the second smart contract; reading from the account of the second smart contract according to the account address Get the compressed target machine code of the second smart contract; decompress the compressed target machine code, and execute the obtained decompressed target machine code.
  • One of the embodiments of this specification provides a system for calling a smart contract in a blockchain.
  • the system is used to: in the process of executing the first smart contract: determine the account address of the second smart contract from the statement calling the second smart contract; read from the account of the second smart contract according to the account address The compressed target machine code of the second smart contract; decompress the compressed target machine code, and execute the obtained decompressed target machine code.
  • One of the embodiments of this specification provides an apparatus for invoking a smart contract in a blockchain.
  • the apparatus includes a processor and a storage device, the storage device is used for storing instructions, and when the processor executes the instructions, the method for invoking a smart contract in a blockchain as described in any embodiment of this specification is implemented.
  • FIG. 1 is a schematic diagram of an application scenario of a blockchain system according to some embodiments of this specification
  • Figure 2 is an exemplary flowchart of a method for deploying a smart contract in a blockchain according to some embodiments of the present specification
  • FIG. 3 is an exemplary flowchart of a method for updating a smart contract in a blockchain according to some embodiments of the present specification
  • FIG. 4 is an exemplary flowchart of a method for invoking a smart contract in a blockchain according to some embodiments of the present specification
  • FIG. 5 is a schematic diagram of the composition of a contract deployment transaction according to some embodiments of this specification.
  • FIG. 6 is a schematic diagram of the composition of a contract invocation transaction according to some embodiments of this specification.
  • FIG. 7 is an exemplary block diagram of a system for deploying smart contracts in a blockchain according to some embodiments of the present specification
  • FIG. 8 is an exemplary block diagram of a system for updating smart contracts in a blockchain according to some embodiments of the present specification
  • FIG. 9 is an exemplary block diagram of a system for invoking a smart contract in a blockchain according to some embodiments of the present specification.
  • system means for distinguishing different components, elements, parts, parts or assemblies at different levels.
  • device means for converting signals into signals.
  • unit means for converting signals into signals.
  • module means for converting signals into signals.
  • a blockchain can be an abbreviation for a blockchain network (node chain) or an abbreviation for blockchain data.
  • the blockchain data may include block data and state data.
  • Block data is formed by linking blocks (data chain, also known as block chain), and usually does not support modification (adding, deleting, changing values).
  • Status data (such as account storage) supports additions, deletions, and revisions, and blockchain data updates (add, delete, and change values) take effect after the consensus is passed.
  • “on-chain” may mean that content or content is written to blockchain data.
  • On-chain can mean that the content is included in the blockchain data, or the result of the operation needs to go through consensus and will affect the update of the blockchain data
  • off-chain can mean that the content is not included in the blockchain data, or the result of the operation There is no need to go through consensus (and naturally it will not affect the update of blockchain data).
  • a smart contract can refer to an agreement that is distributed and stored in each node in the blockchain system in a digital form, which can be automatically executed after being triggered.
  • the smart contract code (referred to as the contract code) is the process of storing the contract code locally after it is created until each blockchain node completes the consensus, that is, the deployment process of the smart contract. After the smart contract is deployed, once the set trigger conditions are met, such as receiving a transaction calling the smart contract, the blockchain node can automatically read and execute the contract code.
  • the compressed contract code is uploaded to the chain, which can save the storage space of the blockchain node.
  • the deployment of smart contracts requires tokens (such as Gas in Ethereum, which has a certain conversion relationship with Ethereum), and the number of tokens consumed is uploaded to
  • the volume of smart contracts in the blockchain network increases, so putting the compressed contract code on the chain can save the cost of tokens.
  • the network transmission bandwidth can be reduced and the time required for transmission can be reduced.
  • the source code of smart contracts is often written in high-level languages, such as BASIC, JAVA, C, C++, Python, etc.
  • Source code written in a high-level language can be converted (compiled) by a compiler into machine code that can be recognized and executed by a CPU (Central Processing Unit, central processing unit).
  • Machine code can also be called microprocessor instructions. This way of converting code written in a high-level language into machine code is called "compiling and executing". Compilation and execution generally do not have cross-platform scalability. Due to differences in one or more of the factors such as the CPU manufacturer, CPU brand, and CPU model, the instruction sets supported by the CPU are often different. For example, some CPUs support the x86 instruction set, and some CPUs support the ARM instruction set.
  • the same program code written in the same high-level language may have different machine codes converted by the compiler on different CPUs.
  • the compiler will combine the characteristics of specific CPU instruction sets (such as vector instruction sets, etc.) to optimize to improve the speed of program execution. Optimizations tend to be specific to the specific CPU hardware.
  • the same machine code can run on a CPU that supports x86, but may not run on a CPU that supports the ARM instruction set. Even though it is also based on the x86 platform, with the passage of time, the instruction set has been continuously enriched and expanded, resulting in the same program code written in the same high-level language being compiled into different machine codes on different generations of x86 platforms.
  • the execution of machine code requires the CPU to be scheduled by the operating system kernel, even on the same CPU, the same program code written in the same high-level language may be compiled into different machine codes under different operating systems.
  • the Java source code is compiled into standard bytecode by the Java compiler.
  • the compiler does not target any actual hardware processor instruction set, but defines a set of abstract Standard instruction set.
  • the compiled bytecode generally cannot run directly on the hardware CPU, so a virtual machine, namely JVM (Java Virtual Machine, Java Virtual Machine), is introduced.
  • JVM Java Virtual Machine, Java Virtual Machine
  • a Java virtual machine is a fictitious computer that is implemented by simulating various computer functions on an actual computer.
  • the JVM shields the information related to the specific hardware platform, operating system, etc., so that as long as the Java program is a standard bytecode that can run on the Java virtual machine, it can run on various platforms without modification.
  • the JVM runs on a specific hardware processor and is responsible for interpreting and executing bytecodes for the specific processor running, shielding these underlying differences upwards, and presenting standard development specifications to developers.
  • the JVM executes the bytecode, it actually finally interprets the bytecode into machine code execution on a specific platform. Specifically, after the JVM receives the input bytecode, it interprets each instruction in it sentence by sentence, and translates it into machine code suitable for the current machine to run, for example, an interpreter (Interpreter) interprets and executes these processes. In this way, developers who write Java programs do not need to consider which hardware platform the program code will run on.
  • the development of the JVM itself is done by professional developers of the Java organization to adapt the JVM to different processor architectures.
  • the contract code for uploading and subsequent invocation may be either byte code or machine code.
  • the contract code on the chain and subsequently invoked may include multiple copies of the machine code corresponding to these machine architectures one-to-one.
  • the matching target machine code is executed.
  • the execution speed/efficiency of machine code is higher, so putting the machine code of the smart contract on the chain and subsequently executing the machine code of the smart contract can make the execution of the smart contract more efficient.
  • the amount of statements required to express in machine code is generally larger than that in byte code. That is, for instructions with the same function, generally speaking, the volume of machine code > the volume of byte code.
  • the volume of the machine code can reach 5 to 10 times that of the byte code. Therefore, putting the compressed machine code of the smart contract on the chain can not only improve the execution efficiency of the smart contract, but also control the storage cost consumed by the contract code and save the network transmission bandwidth and tokens (such as gas) consumed by the contract deployment.
  • FIG. 1 is a schematic diagram of an application scenario of a blockchain system according to some embodiments of this specification.
  • the blockchain system 100 may include a blockchain network 110 and a client 120 .
  • the blockchain network 110 may include a plurality of blockchain nodes (nodes for short), such as node 110-1, node 110-2, node 110-3, . . . , node 110-n.
  • a node in the blockchain network 110 may receive transactions broadcast in the blockchain network 110 and generate new blocks based on the transactions received over a period of time.
  • Transactions can be used to initiate events/behaviors in the blockchain system, for example, transactions for joining blockchain members, transactions for transfers (such as transfers of tokens) (hereinafter referred to as transfer transactions), deployment of smart contracts. Transactions, transactions that invoke smart contracts, and more.
  • Each node (which can be called a consensus node/full node) runs the consensus mechanism, so that each node generates the same block (or the accounting node generates the block) and writes it into the blockchain. That is, the consensus mechanism can ensure that the blockchains saved by each node remain consistent.
  • the blockchain node After receiving the transaction, the blockchain node can perform related operations according to the transaction content, and this process can be called the execution of the transaction.
  • the execution of a transfer transaction includes the transfer of tokens between accounts.
  • the execution of a transaction deploying a smart contract includes deploying the smart contract on the blockchain.
  • the execution of a transaction that invokes a smart contract includes invoking (executing) a smart contract deployed on the chain.
  • each node also runs the consensus mechanism, so that each node can consistently update the state data. That is, the consensus mechanism can also ensure that the state data saved by each node remains consistent.
  • Transactions can be executed through virtual machines under specific blockchain specifications, such as EVM (Ethernet Virtual Machine), virtual machines under WASM (WebAssembly) specifications, and so on.
  • the deployed smart contract may be an EVM-based smart contract (referred to as an EVM contract) or a smart contract under the WASM specification (referred to as a WASM contract).
  • the client 120 may generate and upload the transaction to the blockchain network 110 so that the transaction is broadcast in the blockchain network 110, ie, initiates the transaction.
  • Each consensus node can generate new blocks based on transactions received over a period of time.
  • nodes in the blockchain network 110 may also initiate transactions.
  • the client 120 and the blockchain node may be integrated on the same device.
  • the client 120 may join the blockchain network 110 as a consensus node (full node), or may join the blockchain network 110 as a lightweight node without participating in the consensus.
  • full nodes save more blockchain data (such as block headers and block bodies) to participate in consensus, while light nodes can only save some key blockchain data (such as block headers) and rely on full nodes for verification The authenticity of on-chain content such as transactions.
  • the manner in which transactions are written to blocks may be explicit, ie nodes may write transactions themselves to blocks. In some embodiments, the manner in which transactions are written to blocks may be implicit. For example, a node can write the hash value of the transaction into the block, but in this case, each node can still save the received transaction for verification of transaction integrity (whether it has been tampered with), such as hash value verification.
  • Each consensus node can receive the transaction of deploying the smart contract uploaded to the blockchain network 110, and after running the consensus mechanism, write the smart contract code into the blockchain data, thereby realizing the deployment of the smart contract on the blockchain.
  • each consensus node can receive transactions that invoke smart contracts uploaded to the blockchain network 110 and invoke smart contracts that have been deployed on-chain.
  • nodes in client 120/blockchain network 110 may include various types of computing devices, such as smartphones, laptops, desktops, servers, and the like.
  • the servers may be independent servers or groups of servers, which may be centralized or distributed. In some embodiments, the server may be regional or remote. In some embodiments, the server may execute on a cloud platform.
  • the cloud platform may include one or any combination of a private cloud, a public cloud, a hybrid cloud, a community cloud, a decentralized cloud, an internal cloud, and the like.
  • FIG. 2 is an exemplary flowchart of a method for deploying a smart contract in a blockchain according to some embodiments of the present specification.
  • Process 200 may be performed by consensus nodes in blockchain network 110 . As shown in FIG. 2, the process 200 may include:
  • Step 210 Receive a transaction for deploying a smart contract, where the transaction includes one or more compressed machine codes of the smart contract.
  • step 210 may be implemented by the first transaction receiving module 710 .
  • the transaction initiator ie, the contract deployer
  • a contract deployment transaction a smart contract deployment transaction
  • the machine code placed in the contract deployment transaction may be compiled by compiling the smart contract source code (eg, code written in a high-level language) or intermediate code (eg, bytecode). Also known as “Ahead-of-Time Compilation” or "AoT” (Ahead of Time).
  • uploading the compressed machine code of the smart contract can not only improve the execution efficiency of the smart contract, but also control the storage cost consumed by the contract code and save the transmission bandwidth occupied during the contract deployment process.
  • the source code or intermediate code of the same smart contract can be compiled into multiple machine codes and put into the contract deployment transaction to adapt to different machine architectures running the contract code. That is, the node executing the contract code can select the appropriate version of the machine code to execute according to its own machine architecture.
  • compiling and compressing the source code or intermediate code of smart contracts into machine code off-chain can greatly reduce the processing pressure of on-chain nodes.
  • contract deployers may be forced to include compressed contract code in transactions that deploy smart contracts.
  • the node can check whether the contract code in the received transaction is compressed, and if so, the node can execute the transaction to deploy the smart contract, and the node can refuse to execute the transaction.
  • the code of each smart contract is uploaded in a compressed form, which can greatly save the storage space of blockchain nodes, and can also greatly reduce the cost of tokens and network transmission bandwidth for contract deployment.
  • the option of compression can also be given to the contract deployer. That is, the contract deployer is allowed to freely choose whether to put compressed contract code or uncompressed contract code into the transaction.
  • the contract code may be packaged in a file of a specific format (hereinafter referred to as a contract code file). That is, one or more compressed machine codes of a smart contract can be encapsulated in a contract code file.
  • the uncompressed bytecode of the same smart contract may be packaged together in a contract code file.
  • machine code has undefined behavior and bytecode has a complete definition. Accordingly, bytecode can form a strict correspondence with legally valid business logic, but machine code cannot form a strict correspondence with business logic. . Therefore, putting the bytecode of a smart contract on the chain preserves legally binding evidence.
  • the size of the bytecode itself (uncompressed) is not large, and the impact of the bytecode on the chain of the smart contract on the storage cost is tolerable. It is worth noting that, in general, the size of the bytecode itself (uncompressed) is not large, and the size of the bytecode before and after compression does not change significantly. As mentioned above, the size of the machine code corresponding to the bytecode can reach 5 to 10 times the size of the bytecode. Therefore, compared with compressing the bytecode of the smart contract, it is more significant to compress one or even multiple copies of the machine code of the smart contract.
  • the contract code file may further include an ABI (Application Binary Interface, application binary interface) file, where the ABI file contains description information of the interface provided by the smart contract. Due to the small size of the ABI file, it is not necessary to compress the ABI file in the contract code file. It should be noted that, for a smart contract written in the same high-level language, the bytecode obtained after compilation and the machine code of at least one platform, or the machine code of at least one platform obtained by translation of the bytecode, can be used The same ABI file.
  • ABI Application Binary Interface, application binary interface
  • the contract code file may further include compression information of the smart contract (referred to as contract compression information), and the compression information may indicate whether the machine code of the smart contract in the contract code file is compressed and/or An algorithm for compressing the machine code of the smart contract in the contract code file.
  • contract compression information in the contract code file may be set to indicate that the machine code of the smart contract in the contract code file is compressed and/or or an algorithm for compressing the machine code of the smart contract in the contract code file.
  • the contract code file may also include fields that may indicate initialization of variables in the smart contract (contract variables for short). Specifically, this field may include a key-value pair of the contract variable to be initialized, where the key is the variable name and the value is the initial value. Nodes can initialize contract variables according to this field in the contract code file. Further, the node can write the initialized contract variables into the account storage of the smart contract. For more details on account storage, please refer to the related descriptions below.
  • the contract code file may have a unique identification.
  • the unique identifier can be included in the contract state to indicate the storage location of the contract code file.
  • the unique identifier of the contract code file can be set as the hash value of the contract code file, and whether the contract code file has been tampered with can be confirmed through hash verification.
  • the hash value here can refer to the output obtained by inputting all fields of the contract code file into the hash function.
  • the key can be set as the hash value of the contract code file, and the value can be set as the contract code file.
  • EVM contracts you can use the evm file to encapsulate the contract code.
  • WASM contracts you can use wasm format files or wasc format files to encapsulate smart contract code.
  • the node executing the smart contract can decapsulate the contract code file (such as evm format file/wasm format file/wasc format file) according to the unified specification, and obtain various fields (such as contract code, compressed information, contract compressed field, etc.).
  • Step 220 Create the account and account address of the smart contract, and store the one or more compressed machine codes in the account of the smart contract.
  • step 220 may be implemented by contract deployment module 720 .
  • contract storage The existence of the contract account/deployment of smart contracts can be reflected in the following aspects: 1. Having an address (ie, the contract address), the contract address is used to access the contract account; 2. Having permanent storage, that is, the contract account belongs to the storage of the node, and sometimes also The contract account can be called the storage of smart contracts (referred to as contract storage).
  • the contract store (contract account) may include contract code as well as account store, where the account store may be used to save the state of the contract.
  • the contract account may also have summary information, as opposed to the contract account (storage) itself being the detailed information.
  • the summary information of the contract account is sometimes referred to as the state of the contract account (referred to as the contract state), and the state of the global blockchain account can be referred to as the "world state”.
  • blockchain accounts can also include accounts held by entities, such as external accounts in Ethereum.
  • the contract address indicates the storage location of the contract account (that is, the contract storage) and its related information (such as the contract status), and is used to access the contract account and its related information.
  • the access can refer to the addition, deletion, and modification of data.
  • the contract address (key) and the contract storage/contract state (value) can form a key-value pair (key-value) to be stored on the node.
  • Contract addresses can be generated in various ways.
  • the contract deployment transaction may include an account address of the transaction initiator (ie, the contract deployer) and a first transaction count, where the first transaction count is used to count transactions initiated by the transaction initiator.
  • the node can generate the contract address based on the account address of the transaction initiator and the first transaction count in the contract deployment transaction.
  • the transaction initiator ie, the contract deployer
  • the contract deployer can specify the name of the smart contract (contract name for short) in the contract deployment transaction, and the node can generate the contract address based on the contract name.
  • the contract variables in the account store can also be stored in the form of key-value pairs, with the variable name as the key and the variable value as the value.
  • account storage can be mapped with a Merkle tree, such as an MPT tree (Merkle Patricia Tree).
  • MPT tree Merkle Patricia Tree
  • the Merkle tree stored by the mapped account can be called a storage tree, and each contract account corresponds to a storage tree.
  • the account state may include at least one of the account balance (denoted as balance), second transaction count (denoted as nonce), code hash (denoted as codehash), storage tree root hash (denoted as storageroot), etc.
  • the balance field indicates the balance of the contract account
  • the nonce field is used to count the transactions received by the contract account
  • the codehash field indicates the storage location of the contract code, which can be specifically set as the hash value of the contract code file that encapsulates the contract code
  • storageroot is the hash value corresponding to the root node of the storage tree (referred to as the root hash). It can be understood that initiating a transaction to invoke a smart contract can also be referred to as sending a transaction to the account of the smart contract, that is, the account of the smart contract receives a transaction.
  • the account status may also include a contract compression field that indicates whether the machine code in the contract store is compressed.
  • the node can set the contract compression field in the contract state to indicate whether the machine code of the smart contract in the contract account is compressed. For example, when the contract deployment transaction puts the compressed machine code of the smart contract, the node can set the contract compression field to indicate that the machine code of the smart contract in the contract account is compressed.
  • the node can initialize the contract variables.
  • the contract deployer can instruct the contract variable to be initialized in the contract deployment transaction initiated, for example, package the key and value of the contract variable to be initialized into the contract deployment transaction.
  • the node can initialize the contract variables according to the contract deployment transaction, write the initialized contract variables into the account storage and update the storageroot.
  • FIG. 3 is an exemplary flowchart of a method for updating a smart contract in a blockchain according to some embodiments of the present specification.
  • Process 300 may be performed by consensus nodes in blockchain network 110 . As shown in FIG. 3, the process 300 may include:
  • Step 310 Receive a transaction for updating the smart contract, where the transaction includes the account address of the smart contract and one or more compressed machine codes of the smart contract.
  • step 310 may be implemented by the second transaction receiving module 810 .
  • Step 320 according to the account address of the smart contract, store the compressed smart contract code in the account storage of the smart contract.
  • step 320 may be implemented by contract update module 820 .
  • the update of the smart contract refers to the update of the deployed contract code (such as machine code, byte code), and the contract code before and after the update is stored in the same contract account.
  • the node can write the updated version of the machine code of the smart contract in the contract account according to the updated account address of the smart contract. Specifically, the node can write the new version of the machine code in the transaction of updating the smart contract (referred to as the contract update transaction) into the contract account, overwriting (replacing) the old version of the machine code written in the contract account before.
  • the node can update the account status accordingly, such as updating the codehash field and storageroot field.
  • a smart contract there can be various timings for updating a smart contract. For example, when business needs change, the bytecode and machine code of on-chain smart contracts can be updated. For another example, if a node with a new machine architecture joins the blockchain network, the machine code of the smart contract that is adapted to the new machine architecture can be uploaded to the chain.
  • the account state may also include a contract compression field, which is used to indicate whether the machine code of the smart contract in the contract account is compressed.
  • one or more machine codes of the smart contract in the contract update transaction may be encapsulated into a contract code file, and the contract code file also includes uncompressed bytecodes of the smart contract.
  • a contract update transaction/contract code file may instruct contract variables to be initialized.
  • FIG. 4 is an exemplary flowchart of a method for invoking a smart contract in a blockchain according to some embodiments of the present specification.
  • Process 400 may be performed by consensus nodes in blockchain network 110 .
  • the process 400 may include: Step 410 , receiving a transaction for invoking a smart contract, where the transaction includes an account address of the smart contract.
  • step 410 may be implemented by the third transaction receiving module 910 .
  • the account address of the smart contract can be placed in the transaction of calling a smart contract (referred to as a contract calling transaction), so as to call (read, execute) the machine code of the smart contract in the contract account according to the account address.
  • a contract calling transaction referred to as a contract calling transaction
  • Step 420 Read the compressed target machine code of the smart contract from the account of the smart contract according to the account address.
  • step 420 may be implemented by contract code reading module 920 .
  • Step 430 decompress the compressed target machine code, and execute the obtained decompressed target machine code.
  • step 430 may be implemented by contract execution module 930 .
  • one or more compressed machine codes of the smart contract in the contract storage include the target machine code.
  • the node can select the machine code that is adapted to its own machine architecture as the target machine code.
  • the node may read a contract code file from the contract account according to the account address in the contract invocation transaction, the contract code file including one or more compressed machine codes of the smart contract and The uncompressed bytecode of the smart contract. Further, the node may determine the compressed target machine code from the one or more copies of the compressed machine code.
  • nodes can execute the decompressed target machine code and uncompressed bytecode in the contract code file respectively, and Compare the execution results of the two to verify the reliability of the contract code. If the execution results are consistent, it means that the target machine code and bytecode in the contract code file correspond to the business logic of the same smart contract; otherwise, it means that the target machine code and/or bytecode in the contract code file is unreliable, for example, the contract The target machine code and/or bytecode in the code files may have been tampered with.
  • the contract code file may have a unique identification indicating its storage location, which may be set as a hash value of the contract code file and contained in the summary information (ie, contract state) of the contract account.
  • the node can query the summary information of the contract account according to the account address of the contract account, and read the contract code file according to the unique identifier of the contract code file in the summary information of the contract account.
  • the target machine code of the smart contract read by the node is always compressed. Decompress the read target machine code of the smart contract, and then execute the obtained decompressed target machine code.
  • the contract deployer is allowed to freely choose to put compressed contract code or uncompressed contract code into the transaction, the node needs to first determine whether the read target machine code of the smart contract is compressed . If so, first decompress the compressed target machine code read from the smart contract, and then execute the obtained decompressed target machine code, otherwise the read uncompressed target machine code can be directly executed.
  • the node can query the contract compression field in the summary information of the contract account (ie, the contract status) according to the account address in the contract invocation transaction, and determine the read target according to the contract compression field Whether the machine code is compressed.
  • statements calling other smart contracts may appear in the code of one smart contract.
  • the node may determine the account address of the second smart contract from the statement calling the second smart contract, so as to call the second smart contract.
  • the invocation of the smart contract has been introduced in detail in the previous article, so the invocation of the second smart contract will not be described here.
  • FIG. 5 is a schematic diagram of the composition of a contract deployment transaction according to some embodiments of the present specification. As shown in Figure 5, the contract deployment transaction can include the following fields: from, to, value, data, signature.
  • the from field can be put into the account address of the transaction initiator (ie the contract deployer); the to field is empty to indicate the creation of a contract account; the value field can indicate the number of tokens (such as gas) to be transferred (paid);
  • the data field can be put into the contract code, for example, into the evm format file/wasm format file/wasc file that encapsulates the contract code.
  • the smart contract in the data field can be compressed, and the signature field can be put into a digital signature, which can be obtained by encrypting the digest of the message composed of the aforementioned fields with the account private key of the transaction initiator. .
  • the field composition of the contract update transaction is similar, the difference is that: the to field can be put into the account address of the updated smart contract, and the data field can be put into the new version of the contract code.
  • FIG. 6 is a schematic diagram of the composition of a contract invocation transaction according to some embodiments of the present specification.
  • a smart contract invocation transaction can include the following fields: from, to, value, data, signature.
  • the from field can be put into the account address of the transaction initiator (that is, the contract caller); the to field can be put into the account address of the calling smart contract; the value field can indicate the number of tokens (such as gas) to be transferred (paid). ;
  • the data field can be put into the function and its input parameters in the called smart contract; the signature field can be put into a digital signature, which can be obtained by encrypting the digest of the message composed of the aforementioned fields with the account private key of the transaction initiator .
  • the transaction composition shown in FIG. 5 and FIG. 6 is only an example, and various modifications can be made to the transaction composition related to the smart contract under the guidance of this specification.
  • the various fields of the transaction can have arbitrary names.
  • the value field could also be named the amount field.
  • FIG. 7 is an exemplary block diagram of a system for deploying smart contracts in a blockchain according to some embodiments of the present specification. As shown in FIG. 7 , the system 700 may include a first transaction receiving module 710 and a contract deployment module 720 .
  • the first transaction receiving module 710 may be configured to receive a transaction for deploying a smart contract, the transaction including one or more compressed machine codes of the smart contract.
  • the contract deployment module 720 may be configured to create an account and account address of the smart contract, and store the one or more compressed machine codes in the account of the smart contract.
  • the system 800 may include a second transaction receiving module 810 and a contract updating module 820 .
  • the second transaction receiving module 810 may be configured to receive a transaction for updating the smart contract, where the transaction includes the account address of the smart contract and one or more compressed machine codes of the smart contract.
  • the contract update module 820 may be configured to store the one or more compressed machine codes in the account of the smart contract according to the account address of the smart contract.
  • FIG. 9 is an exemplary block diagram of a system for invoking a smart contract in a blockchain according to some embodiments of the present specification.
  • the system 900 may include a third transaction receiving module 910 , a contract code reading module 920 and a contract executing module 930 .
  • the third transaction receiving module 910 may be configured to receive a transaction invoking a smart contract, where the transaction includes an account address of the smart contract.
  • the contract code reading module 920 may be configured to read the compressed target machine code of the smart contract from the account of the smart contract according to the account address.
  • the contract execution module 930 may be configured to decompress the compressed target machine code, and execute the obtained decompressed target machine code.
  • the contract execution module 930 can determine the account address of the second smart contract from the statement calling the second smart contract, according to the account address from the second smart contract.
  • the compressed target machine code of the second smart contract is read in the account of the smart contract, the compressed target machine code is decompressed, and the obtained decompressed target machine code is executed.
  • FIGS. 2-6 For more details of the above system and its modules, reference may be made to the related descriptions of FIGS. 2-6 .
  • system and its modules shown in FIGS. 7-9 can be implemented in various ways.
  • the system and its modules may be implemented in hardware, software, or a combination of software and hardware.
  • the hardware part can be realized by using dedicated logic;
  • the software part can be stored in a memory and executed by a suitable instruction execution system, such as a microprocessor or specially designed hardware.
  • a suitable instruction execution system such as a microprocessor or specially designed hardware.
  • the methods and systems described above may be implemented using computer-executable instructions and/or embodied in processor control code, for example on a carrier medium such as a disk, CD or DVD-ROM, such as a read-only memory (firmware) ) or a data carrier such as an optical or electronic signal carrier.
  • the system and its modules of this specification can be implemented not only by hardware circuits such as very large scale integrated circuits or gate arrays, semiconductors such as logic chips, transistors, etc., or programmable hardware devices such as field programmable gate arrays, programmable logic devices, etc. , can also be implemented by, for example, software executed by various types of processors, and can also be implemented by a combination of the above-mentioned hardware circuits and software (eg, firmware).
  • the above description of the system and its modules is only for the convenience of description, and does not limit the description to the scope of the illustrated embodiments. It can be understood that for those skilled in the art, after understanding the principle of the system, various modules may be combined arbitrarily, or a subsystem may be formed to connect with other modules without departing from the principle.
  • the contract code reading module 920 and the contract execution module 930 may be two modules, or may be combined into one module. Such deformations are all within the protection scope of this specification.
  • the possible beneficial effects of the embodiments of this specification include, but are not limited to: (1) uploading the machine code to the chain for invocation, which can greatly improve the execution efficiency of the smart contract; (2) compressing the machine code of the smart contract before uploading to the chain , which can greatly save the storage cost, token and network transmission bandwidth of deploying smart contracts. It should be noted that different embodiments may have different beneficial effects, and in different embodiments, the possible beneficial effects may be any one or a combination of the above, or any other possible beneficial effects.
  • aspects of the embodiments of this specification may be illustrated and described in several patentable classes or situations, including any new and useful process, machine, product, or combination of matter, or Any new and useful improvements to them.
  • various aspects of the embodiments of the present specification may be fully implemented by hardware, may be fully implemented by software (including firmware, resident software, microcode, etc.), or may be implemented by a combination of hardware and software.
  • the above hardware or software may be referred to as a "data block”, “module”, “engine”, “unit”, “component” or “system”.
  • aspects of the embodiments of this specification may be embodied as a computer product comprising computer readable program code on one or more computer readable media.
  • a computer storage medium may contain a propagated data signal with the computer program code embodied therein, for example, on baseband or as part of a carrier wave.
  • the propagating signal may take a variety of manifestations, including electromagnetic, optical, etc., or a suitable combination.
  • Computer storage media can be any computer-readable media other than computer-readable storage media that can communicate, propagate, or transmit a program for use by coupling to an instruction execution system, apparatus, or device.
  • Program code on a computer storage medium may be transmitted over any suitable medium, including radio, cable, fiber optic cable, RF, or the like, or a combination of any of the foregoing.
  • the computer program codes required for the operations of the various parts of the embodiments of this specification can be written in any one or more programming languages, including object-oriented programming languages such as Java, Scala, Smalltalk, Eiffel, JADE, Emerald, C++, C#, VB.NET , Python, etc., conventional programming languages such as C language, VisualBasic, Fortran2003, Perl, COBOL2002, PHP, ABAP, dynamic programming languages such as Python, Ruby and Groovy, or other programming languages.
  • the program code may run entirely on the user's computer, or as a stand-alone software package on the user's computer, or partly on the user's computer and partly on a remote computer, or entirely on the remote computer or processing device.
  • the remote computer can be connected to the user's computer through any network, such as a local area network (LAN) or wide area network (WAN), or to an external computer (eg, through the Internet), or in a cloud computing environment, or as a service Use eg software as a service (SaaS).
  • LAN local area network
  • WAN wide area network
  • SaaS software as a service

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • General Business, Economics & Management (AREA)
  • Computing Systems (AREA)
  • Finance (AREA)
  • Data Mining & Analysis (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

一种在区块链中部署、更新、调用智能合约的方法。方法包括：在部署或更新智能合约时，将智能合约的一份或多份经过压缩的机器码上链。相应地，在调用智能合约时，根据合约地址读取智能合约的经过压缩的目标机器码，并在解压缩后执行。

Description

一种在区块链中部署、更新、调用智能合约的方法 技术领域
本说明书涉及信息技术领域，特别涉及一种在区块链中部署、更新、调用智能合约的方法。
背景技术
智能合约分布式地存储于区块链网络中。当智能合约代码体积(存储大小)增大或数量增多时，智能合约持久化存储到区块链中会耗费大量存储空间，带来存储成本的上升。
因此，目前需要提供一种节省存储空间的智能合约部署方案。
发明内容
本说明书实施例之一提供一种在区块链中部署智能合约的方法。所述方法包括：接收部署智能合约的交易，所述交易包括所述智能合约的一份或多份经过压缩的机器码；创建所述智能合约的账户和账户地址，并在所述智能合约的账户中存储所述一份或多份经过压缩的机器码。
本说明书实施例之一提供一种在区块链中部署智能合约的装置。所述装置包括处理器和存储设备，所述存储设备用于存储指令，当所述处理器执行指令时，实现如本说明书任一实施例所述的在区块链中部署智能合约的方法。
本说明书实施例之一提供一种在区块链中部署智能合约的系统。所述系统包括第一交易接收模块和合约部署模块。所述第一交易接收模块接收部署智能合约的交易，所述交易包括所述智能合约的一份或多份经过压缩的机器码。所述合约部署模块用于创建所述智能合约的账户和账户地址，并在所述智能合约的账户中存储所述一份或多份经过压缩的机器码。
本说明书实施例之一提供一种在区块链中更新智能合约的方法。所述方法包括：接收更新智能合约的交易，所述交易包括所述智能合约的账户地址和所述智能合约的一份或多份经过压缩的机器码；根据所述智能合约的账户地址，在所述智能合约的账户中存储所述一份或多份经过压缩的机器码。
本说明书实施例之一提供一种在区块链中更新智能合约的装置。所述装置包括处理器和存储设备，所述存储设备用于存储指令，当所述处理器执行指令时，实现如如本说明书任一实施例所述的在区块链中更新智能合约的方法。
本说明书实施例之一提供一种在区块链中更新智能合约的系统。所述系统包括第二 交易接收模块和合约更新模块。所述第二交易接收模块用于接收更新智能合约的交易，所述交易包括所述智能合约的账户地址和所述智能合约的一份或多份经过压缩的机器码。所述合约更新模块用于根据所述智能合约的账户地址，在所述智能合约的账户中存储所述一份或多份经过压缩的机器码。
本说明书实施例之一提供一种在区块链中调用智能合约的方法。所述方法包括：接收调用智能合约的交易，所述交易包括所述智能合约的账户地址；根据所述账户地址从所述智能合约的账户中读取所述智能合约的经过压缩的目标机器码；对所述经过压缩的目标机器码进行解压缩，并执行得到的解压缩后的目标机器码。
本说明书实施例之一提供一种在区块链中调用智能合约的系统。所述系统包括第三交易接收模块、合约代码读取模块和合约执行模块。所述第三交易接收模块用于接收调用智能合约的交易，所述交易包括所述智能合约的账户地址。所述合约代码读取模块用于根据所述账户地址从所述智能合约的账户中读取所述智能合约的经过压缩的目标机器码。所述合约执行模块用于对所述经过压缩的目标机器码进行解压缩，并执行得到的解压缩后的目标机器码。
本说明书实施例之一提供一种在区块链中调用智能合约的方法。所述方法包括，在执行第一智能合约代码的过程中：从调用第二智能合约的语句中确定第二智能合约的账户地址；根据所述账户地址从所述第二智能合约的账户中读取所述第二智能合约的经过压缩的目标机器码；对所述经过压缩的目标机器码进行解压缩，并执行得到的解压缩后的目标机器码。
本说明书实施例之一提供一种在区块链中调用智能合约的系统。所述系统用于在执行第一智能合约的过程中：从调用第二智能合约的语句中确定第二智能合约的账户地址；根据所述账户地址从所述第二智能合约的账户中读取所述第二智能合约的经过压缩的目标机器码；对所述经过压缩的目标机器码进行解压缩，并执行得到的解压缩后的目标机器码。
本说明书实施例之一提供一种在区块链中调用智能合约的装置。所述装置包括处理器和存储设备，所述存储设备用于存储指令，当所述处理器执行指令时，实现如本说明书任一实施例所述的在区块链中调用智能合约的方法。
附图说明
本说明书将以示例性实施例的方式进一步说明，这些示例性实施例将通过附图进行详细描述。这些实施例并非限制性的，在这些实施例中，相同的编号表示相同的结构，其中：
图1是根据本说明书一些实施例所示的区块链系统的应用场景示意图；
图2是根据本说明书一些实施例所示的在区块链中部署智能合约的方法的示例性流 程图；
图3是根据本说明书一些实施例所示的在区块链中更新智能合约的方法的示例性流程图；
图4是根据本说明书一些实施例所示的在区块链中调用智能合约的方法的示例性流程图；
图5是根据本说明书一些实施例所示的合约部署交易的组成示意图；
图6是根据本说明书一些实施例所示的合约调用交易的组成示意图；
图7是根据本说明书一些实施例所示的在区块链中部署智能合约的系统的示例性模块图；
图8是根据本说明书一些实施例所示的在区块链中更新智能合约的系统的示例性模块图；
图9是根据本说明书一些实施例所示的在区块链中调用智能合约的系统的示例性模块图。
具体实施方式
为了更清楚地说明本说明书实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单的介绍。显而易见地，下面描述中的附图仅仅是本说明书的一些示例或实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图将本说明书应用于其它类似情景。除非从语言环境中显而易见或另做说明，图中相同标号代表相同结构或操作。
应当理解，本文使用的“系统”、“装置”、“单元”和/或“模组”是用于区分不同级别的不同组件、元件、部件、部分或装配的一种方法。然而，如果其他词语可实现相同的目的，则可通过其他表达来替换所述词语。
如本说明书中所示，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。一般说来，术语“包括”与“包含”仅提示包括已明确标识的步骤和元素，而这些步骤和元素不构成一个排它性的罗列，方法或者设备也可能包含其它的步骤或元素。
本说明书中使用了流程图用来说明根据本说明书的实施例的系统所执行的操作。应当理解的是，前面或后面操作不一定按照顺序来精确地执行。相反，可以按照倒序或同时处理各个步骤。同时，也可以将其他操作添加到这些过程中，或从这些过程移除某一步或数步操作。
在本说明书中，取决于具体的语境，“区块链”一词(有时也简称“链”)的含义是灵 活的。例如，区块链可以是对区块链网络(节点链)的简称，也可以是对区块链数据的简称。其中，区块链数据可以包括区块数据和状态数据。区块数据由区块链接而成(数据链，也可称为区块链)，通常不支持修改(新增、删除、变更值)。状态数据(如账户存储)支持增删查改，区块链数据的更新(新增、删除、变更值)在共识通过后生效。另外，“上链”可表示将内容或内容被写入区块链数据。“链上”可表示内容包含在区块链数据中，或操作结果需要经过共识并会影响区块链数据的更新，“链下”可表示内容不包含在区块链数据中，或操作结果无需经过共识(自然也不会影响区块链数据的更新)。
智能合约(简称合约)可以指以数字形式分布式存储于区块链系统中各节点的协议，其在被触发后可以自动执行。智能合约代码(简称合约代码)从被创建到各区块链节点完成共识后将合约代码存储于本地的过程即智能合约的部署过程。智能合约被部署后，一旦满足设定的触发条件，例如接收到调用智能合约的交易，区块链节点可以自动地读取并执行合约代码。
开发人员根据实际的业务逻辑编写合约代码。当业务逻辑逐渐复杂后，智能合约的代码体积(存储大小)也会变大。随着智能合约的持续部署，区块链节点存储的智能合约数量也会持续增加，从而导致合约代码占用的存储空间增加。
有鉴于此，本说明书实施例中将经过压缩的合约代码上链，可以节省区块链节点的存储空间。在一些区块链架构(如以太坊或类似架构)中，部署智能合约需要耗费通证(如以太坊中的Gas，与以太币间具有一定换算关系)，且消耗的通证数量随上传至区块链网络的智能合约体积的增加而增加，因此将经过压缩的合约代码上链可以节省耗费的通证。另外，通过压缩合约代码，可以降低网络传输带宽，减少传输所需的时间。
智能合约的源代码往往用高级语言来编写，如BASIC、JAVA、C、C++、Python等。用高级语言编写好的源代码，可由编译器转换(编译)为CPU(Central Processing Unit，中央处理单元)可以识别和执行的机器码，机器码也可称为微处理器指令。这种将用高级语言编写的代码转换成机器码的方式被称为“编译执行”。编译执行一般不具有跨平台的可拓展性，由于CPU厂商、CPU品牌、CPU型号等因素中的一个或多个的不同，CPU支持的指令集往往也不同。例如，一些CPU支持x86指令集，一些CPU支持ARM指令集。因此，用同一高级语言编写的同一程序代码，在不同CPU上被编译器转换得到的机器码可能不同。具体地，编译器在将用高级语言编写的程序代码转换成机器码的过程中，会结合具体的CPU指令集的特点(如向量指令集等)进行优化以提升程序执行的速度，而此类优化往往与具体的CPU硬件相关。如此，相同的机器码在支持x86的CPU上可以运行，但在支持ARM指令集的CPU上就可能无法运行。甚至虽同样基于x86平台，但随着时间的推移，指令集不断丰富和扩展，导致用同一高级语言编写的同一程序代码在不同代的x86平台被编译成不同的机器码。另外，由于执行机器码需要由操作系统内核对CPU进行调度，因此即使是同样的CPU，用同一高级语言编写的同一程序代码在不同操作系统下也可能被编译成不同的机器码。
区别于编译执行，还存在一种“解释执行”的程序执行方式。比如在Java语言中，将Java源代码通过Java的编译器编译成标准的字节码(bytecode)，这里编译器不针对于任何实际的硬件处理器的指令集，而是定义了一套抽象的标准指令集。编译成的字节码一般无法在硬件CPU上直接运行，因此引入了一个虚拟机，即JVM(Java Virtual Machine，Java虚拟机)。Java虚拟机是一种虚构的计算机，通过在实际的计算机上仿真模拟各种计算机功能来实现。JVM屏蔽了与具体的硬件平台、操作系统等相关的信息，使得Java程序只要是可在Java虚拟机上运行的标准字节码，就可以在多种平台上不加修改地运行。
JVM运行在特定的硬件处理器上，负责针对所运行的特定处理器而进行字节码的解释和执行，并向上屏蔽这些底层的差异，呈现给开发者以标准的开发规范。JVM在执行字节码时，实际上最终还是把字节码解释成具体平台上的机器码执行。具体地，JVM接收到输入的字节码后，逐句解释其中的每一条指令，并翻译成适合当前机器的机器码来运行，这些过程例如由解释器(Interpreter)进行解释和执行。这样一来，编写Java程序的开发者不需要考虑编写后的程序代码将运行在哪种硬件平台上。JVM本身的开发是由Java组织的专业开发人员完成，以将JVM适配到不同的处理器架构上。迄今为止，主流的处理器架构只有有限的几种，如X86、ARM、RISC-V、MIPS。专业的开发人员将JVM分别移植到支持这几种特定硬件的平台后，Java程序理论上就可以在所有的机器上运行了。JVM的移植工作通常由Java开发组织专业的人员提供的，这就极大减轻了Java程序开发者的负担。
在一些实施例中，上链以及后续调用的合约代码既可以是字节码，也可以是机器码。当区块链网络中的节点具有多种机器架构时，上链以及后续调用的合约代码可包括与这些机器架构一一对应的多份机器码，具备特定机器架构的节点可调用与自身机器架构匹配的目标机器码执行。
相较于字节码，机器码的执行速度/效率更高，因此将智能合约的机器码上链且后续执行智能合约的机器码可以使智能合约的执行效率更高。然而，对于同样功能的指令，用机器码来表达所需的语句量一般大于字节码。即，对于同样功能的指令，一般来说机器码的体积＞字节码的体积。具体地，对于同样功能的指令，机器码的体积可达到字节码体积的5～10倍。因此，将智能合约的经过压缩的机器码上链，不仅可以提高智能合约的执行效率，还可以控制合约代码消耗的存储成本以及节省合约部署耗费的网络传输带宽和通证(如gas)。
图1是根据本说明书一些实施例所示的区块链系统的应用场景示意图。如图1所示，区块链系统100可以包括区块链网络110和用户端120。
区块链网络110可以包括多个区块链节点(简称节点)，如节点110-1、节点110-2、节点110-3、...、节点110-n。一般地，区块链网络110中的一个节点可以接收在区块链网络110中广播的交易，并基于一段时间内接收到的交易生成新区块。交易可用于发起 区块链系统中的事件/行为，例如，用于加入区块链成员的交易、用于转账(例如通证的转移)的交易(以下称为转账交易)，部署智能合约的交易、调用智能合约的交易等等。各节点(可称为共识节点/全量节点)通过运行共识机制，使得各节点生成相同的区块(或者是记账节点生成区块)并将其写入区块链。即，共识机制可确保各节点保存的区块链维持一致。
接收到交易后，区块链节点可以根据交易内容执行相关操作，此过程可称为交易的执行。例如，转账交易的执行包括在账户间转移通证。又如，部署智能合约的交易的执行包括在区块链上部署智能合约。又如，调用智能合约的交易的执行包括调用(执行)链上部署的智能合约。生成区块的过程中，各节点也通过运行共识机制，使得各节点对状态数据进行一致的更新。即，共识机制也可确保各节点保存的状态数据维持一致。
交易可以通过特定区块链规范下的虚拟机执行，例如，EVM(Ethernet Virtual Machine，以太坊虚拟机)、WASM(WebAssembly)规范下的虚拟机等等。在一些实施例中，部署的智能合约可以是基于EVM的智能合约(简称EVM合约)，也可以是WASM规范下的智能合约(简称WASM合约)。
用户端120可以生成交易并将其上传至区块链网络110，以使交易在区块链网络110中广播，即发起交易。各共识节点可基于一段时间内接收到的交易生成新区块。在一些实施例中，区块链网络110中的节点也可以发起交易。
在一些实施例中，用户端120和区块链节点可以集成于同一设备上。在一些实施例中，用户端120可以作为共识节点(全量节点)加入区块链网络110，也可以作为轻量节点加入区块链网络110而不用参与共识。一般地，全量节点保存更多的区块链数据(如区块头和区块体)以参与共识，而轻量节点可以只保存一些关键的区块链数据(如区块头)并依靠全量节点验证链上内容(如交易)的真实性。
在一些实施例中，交易写入区块的方式可以是显式的，即节点可以将交易本身写入区块。在一些实施例中，交易写入区块的方式可以是隐式的。例如，节点可以将交易的哈希值写入区块，但此情况下各节点仍可保存接收到的交易，以备交易完整性(是否被篡改)验证，如哈希值校验。
各共识节点可以接收上传至区块链网络110的部署智能合约的交易，并在运行共识机制后将智能合约代码写入区块链数据，从而实现在区块链上部署智能合约。对于已部署的智能合约，各共识节点可以接收上传至区块链网络110的调用智能合约的交易，并调用已在链上部署的智能合约。
关于智能合约的部署、更新和调用，可以进一步参考图2～6及其相关描述。
在一些实施例中，用户端120/区块链网络110中的节点可以包括各类计算设备，如智能电话、膝上型计算机、台式计算机、服务器等等。
在一些实施例中，服务器可以是独立的服务器或者服务器组，该服务器组可以是集中式的或者分布式的。在一些实施例中，服务器可以是区域的或者远程的。在一些实施例中，服务器可在云平台上执行。例如，该云平台可包括私有云、公共云、混合云、社区云、分散式云、内部云等中的一种或其任意组合。
图2是根据本说明书一些实施例所示的在区块链中部署智能合约的方法的示例性流程图。流程200可以由区块链网络110中的共识节点执行。如图2所示，流程200可以包括：
步骤210，接收部署智能合约的交易，所述交易包括所述智能合约的一份或多份经过压缩的机器码。在一些实施例中，步骤210可以由第一交易接收模块710实现。
参考前文的相关描述，交易发起方(即合约部署方)可以通过用户端120或节点发起部署智能合约的交易(以下简称合约部署交易)。关于合约部署交易的更多字段，可以参考图5及其相关描述。
在一些实施例中，放入合约部署交易中的机器码可以通过对智能合约的源代码(如，用高级语言编写的代码)或中间代码(如字节码)进行编译得，这种编译方式也称为“提前编译”或“AoT”(Ahead of Time)。
参考前述内容，将智能合约的经过压缩的机器码上链，不仅可以提高智能合约的执行效率，还可以控制合约代码消耗的存储成本以及节省合约部署过程中占用的传输带宽。可以理解，同一智能合约的源代码或中间代码可被编译成多份机器码放入合约部署交易，以适配运行合约代码的不同机器架构。即，执行合约代码的节点可以根据自身的机器架构选择合适版本的机器码执行。此外，在链下将智能合约的源代码或中间代码编译成机器码并进行压缩，可以极大地减轻链上节点的处理压力。
在一些实施例中，可以强制要求合约部署方在部署智能合约的交易中放入经过压缩的合约代码。例如，节点可以检查接收到的交易中的合约代码是否是经过压缩，若是，则节点可以执行交易以部署智能合约，节点可以拒绝执行交易。如此，每份智能合约的代码都以压缩形式上链，可以极大地节省区块链节点的存储空间，也可以大大降低合约部署耗费通证和网络传输带宽。
在另一些实施例中，也可以把压缩的选择权交给合约部署方。即，允许合约部署方自由选择将经过压缩的合约代码还是未经压缩的合约代码放入交易中。
在一些实施例中，可以用特定格式的文件(以下称为合约代码文件)封装合约代码。即，可以用合约代码文件封装智能合约的一份或多份经过压缩的机器码。在一些实施例中，除了智能合约的机器码外，还可以将同一智能合约的未经压缩的字节码一起封装于合约代码文件中。机器码在一些情况下存在未定义行为而字节码具有完整的定义，相应地，字节码可以与具备法律效力的业务逻辑构成严格的对应关系而机器码无法与业务逻辑构成严格的对应关系。因此，将智能合约的字节码上链可保留具备法律效力的证据。 可以理解，一般来说字节码本身(未经压缩)的体积并不大，智能合约的字节码上链对存储成本的影响是可以容忍的。值得说明的是，一般来说字节码本身(未经压缩)的体积并不大，压缩前后的字节码的体积变化也不明显。如前所述，对应字节码的机器码，其体积可达到字节码体积的5～10倍。因此，相较于压缩智能合约的字节码，压缩智能合约的一份甚至多份机器码的意义更为重大。
在一些实施例中，合约代码文件还可以包括ABI(Application Binary Interface，应用二进制接口)文件，ABI文件包含智能合约提供的接口的描述信息。由于ABI文件的体积很小，可以不对合约代码文件中的ABI文件进行压缩。需要说明的是，对于同一高级语言编写而成智能合约，其经过编译后得到的字节码和至少一个平台的机器码，或者由字节码翻译而得到的至少一个平台的机器码，可以使用同一个ABI文件。
在一些实施例中，所述合约代码文件还可以包括智能合约的压缩信息(简称合约压缩信息)，所述压缩信息可指示所述合约代码文件中的智能合约的机器码是否经过压缩和/或用于压缩所述合约代码文件中的智能合约的机器码的算法。当合约代码文件中放入的是智能合约的经过压缩的机器码时，合约代码文件中的合约压缩信息可被设置为指示所述合约代码文件中的智能合约的机器码是经过压缩的和/或用于压缩所述合约代码文件中的智能合约的机器码的算法。
在一些实施例中，合约代码文件还可以包括可以指示对智能合约中的变量(简称合约变量)进行初始化的字段。具体地，该字段可以包括要初始化的合约变量的键值对，键(key)为变量名，value为初始值。节点可以根据合约代码文件中的该字段对合约变量进行初始化。进而，节点可以将经过初始化的合约变量写入智能合约的账户存储中。关于账户存储的更多细节，可以参考后文的相关描述。
在一些实施例中，合约代码文件可具有唯一标识。该唯一标识可包含于合约状态中，用于指示合约代码文件的存储位置。具体地，可以将合约代码文件的唯一标识设置为该合约代码文件的哈希值，通过哈希校验可以确认合约代码文件是否被篡改过。可以理解，这里的哈希值可指将合约代码文件的所有字段输入哈希函数后得到的输出。采用k-v存储时，可以将key(键)设置为合约代码文件的哈希值，将value设置为合约代码文件。
对于EVM合约，可以使用evm文件封装合约代码。对于WASM合约，可以使用wasm格式文件或wasc格式文件封装智能合约代码。执行智能合约的节点可以根据统一的规范对合约代码文件(如evm格式文件/wasm格式文件/wasc格式文件)进行解封装，得到各个字段(如合约代码、压缩信息、合约压缩字段等)。
步骤220，创建所述智能合约的账户和账户地址，并在所述智能合约的账户中存储所述一份或多份经过压缩的机器码。在一些实施例中，步骤220可以由合约部署模块720实现。
合约账户的存在/智能合约的部署可体现在以下方面：1.具有地址(即合约地址)， 合约地址用于访问合约账户；2.具有永久性存储，即合约账户属于节点的存储，有时也可将合约账户称作智能合约的存储(简称合约存储)。在一些实施例中，合约存储(合约账户)可包括合约代码以及账户存储，其中，账户存储可用于保存合约的状态。
在一些实施例中，合约账户还可以具有概要信息，相对地合约账户(存储)本身即详细信息。有时也将合约账户的概要信息称作合约账户的状态(简称合约状态)，全局区块链账户的状态可称作“世界状态”。其中，除了合约账户，区块链账户还可包括实体持有的账户，例如以太坊中的外部账户。
合约地址指示合约账户(即合约存储)及其相关信息(如合约状态)的存储位置，用于访问合约账户及其相关信息，这里的访问可以指数据的增删查改。具体地，合约地址(key)与合约存储/合约状态(value)可组成键值对(key-value)存储于节点。
合约地址可通过各种方式生成。在一些实施例中，合约部署交易可包括交易发起方(即合约部署方)的账户地址和第一交易计数，第一交易计数用于对交易发起方发起的交易进行计数。节点可以基于合约部署交易中交易发起方的账户地址和第一交易计数生成合约地址。在一些实施例中，交易发起方(即合约部署方)可以在合约部署交易中指定智能合约的名称(简称合约名称)，节点可以基于该合约名称生成合约地址。
在一些实施例中，账户存储中的合约变量也可以键值对(key-value)形式存储，变量名作为键(key)，变量值作为值(value)。逻辑上，账户存储可以用默克尔(Merkle)树，例如MPT树(Merkle Patricia Tree)，来映射。为了便于描述，可以将映射账户存储的默克尔树称为存储树(storage tree)，每个合约账户对应一棵存储树。
仅作为示例，账户状态可以包括账户余额(记为balance)、第二交易计数(记为nonce)、代码哈希(记为codehash)、存储树根哈希(记为storageroot)等字段中的至少一个。其中，balance字段指示合约账户的余额；nonce字段用于对合约账户接收到的交易进行计数；codehash字段指示合约代码的存储位置，具体可被设置为封装合约代码的合约代码文件的哈希值；storageroot为存储树的根节点对应的哈希值(简称根哈希)。可以理解，发起调用智能合约的交易，也可称作向该智能合约的账户发送了一笔交易，即该智能合约的账户接收到一笔交易。
在一些实施例中，账户状态还可以包括指示合约存储中的机器码是否经过压缩的合约压缩字段。在创建合约账户的过程中，节点可以对合约状态中的合约压缩字段进行设置，以指示合约账户中的智能合约的机器码是否经过压缩。例如，当合约部署交易中放入的是智能合约的经过压缩的机器码时，节点可以将将合约压缩字段设置为指示合约账户中的智能合约的机器码是经过压缩的。
在创建合约账户的过程中，节点可以对合约变量进行初始化。合约部署方可以在发起的合约部署交易中指示对合约变量进行初始化，例如，将要初始化的合约变量的key和value打包进合约部署交易。相应地，节点可根据合约部署交易对合约变量进行初始 化，将经过初始化的合约变量写入账户存储并更新storageroot。
图3是根据本说明书一些实施例所示的在区块链中更新智能合约的方法的示例性流程图。流程300可以由区块链网络110中的共识节点执行。如图3所示，流程300可以包括：
步骤310，接收更新智能合约的交易，所述交易包括所述智能合约的账户地址和所述智能合约的一份或多份经过压缩的机器码。在一些实施例中，步骤310可以由第二交易接收模块810实现。
步骤320，根据所述智能合约的账户地址，在所述智能合约的账户存储中存储所述压缩后的智能合约代码。在一些实施例中，步骤320可以由合约更新模块820实现。
智能合约的更新是指更新已部署的合约代码(如，机器码、字节码)，更新前后的合约代码存储于同一合约账户。节点可根据更新的智能合约的账户地址，在合约账户中写入智能合约的更新版本的机器码。具体地，节点可将更新智能合约的交易(简称合约更新交易)中的新版本的机器码写入合约账户中，覆盖(替换)之前写入合约账户中的旧版本的机器码。随着合约账户(合约存储)的内容发生变化，节点可对账户状态进行相应的更新，如更新codehash字段和storageroot字段。
更新智能合约的时机可以有多种。例如，当业务需求发生变化时，可以对链上的智能合约的字节码和机器码进行更新。又如，若具有新机器架构的节点加入区块链网络，则可以将智能合约的适配于新机器架构的机器码上链。
关于合约更新的更多细节，可以参考合约部署的相关描述。例如，账户状态还可以包括合约压缩字段，合约压缩字段用于指示合约账户中的智能合约的机器码是否经过压缩。又如，又如，合约更新交易中的智能合约的一份或多份机器码可以被封装进合约代码文件中，所述合约代码文件还包括所述智能合约的未经压缩的字节码。又如，合约更新交易/合约代码文件可指示对合约变量进行初始化。
图4是根据本说明书一些实施例所示的在区块链中调用智能合约的方法的示例性流程图。流程400可以由区块链网络110中的共识节点执行。如图4所示，流程400可以包括：步骤410，接收调用智能合约的交易，所述交易包括所述智能合约的账户地址。在一些实施例中，步骤410可以由第三交易接收模块910实现。
参考前述内容，调用智能合约的交易(简称合约调用交易)中可放入所述智能合约的账户地址，以根据所述账户地址调用(读取、执行)合约账户中所述智能合约的机器码。关于合约调用交易的更多字段，可以参考图6及其相关描述。
步骤420，根据所述账户地址从所述智能合约的账户中读取所述智能合约的经过压缩的目标机器码。在一些实施例中，步骤420可以由合约代码读取模块920实现。
步骤430，对所述经过压缩的目标机器码进行解压缩，并执行得到的解压缩后的目 标机器码。在一些实施例中，步骤430可以由合约执行模块930实现。
可以理解，合约存储中的智能合约的一份或多份经过压缩的机器码包括所述目标机器码。当有与多种机器架构一一适配的多份机器码时，节点可选择适配于自身机器架构的机器码作为所述目标机器码。
参考前述内容，在一些实施例中，节点可以根据合约调用交易中的账户地址从合约账户中读取合约代码文件，所述合约代码文件包括智能合约的一份或多份经过压缩的机器码以及所述智能合约的未经压缩的字节码。进而，节点可以从所述一份或多份经过压缩的机器码中确定所述经过压缩的目标机器码。
值得说明的是，在一些场景(如执行参与过共识的历史交易，即交易重放)下，节点可以分别执行合约代码文件中解压缩后的目标机器码和未经压缩的字节码，并比较两者的执行结果，以验证合约代码的可靠性。若执行结果一致，说明合约代码文件中的目标机器码和字节码对应同一智能合约的业务逻辑，否则说明合约代码文件中的目标机器码和/或字节码是不可靠的，例如，合约代码文件中的目标机器码和/或字节码可能经过篡改。
在一些实施例中，合约代码文件可以具有指示其存储位置的唯一标识，该唯一标识可被设置为合约代码文件的哈希值且包含于合约账户的概要信息(即合约状态)。相应地，节点可以根据合约账户的账户地址查询合约账户的概要信息，并根据合约账户的概要信息中的合约代码文件的唯一标识读取合约代码文件。
在一些实施例中，若强制合约部署方在合约部署交易中放入智能合约的经过压缩的机器码，则节点读取到的智能合约的目标机器码总是经过压缩的，因此节点可默认先对读取到的智能合约的目标机器码进行解压缩，再执行得到的解压缩后的目标机器码。在另一些实施例中，若允许合约部署方自由选择将经过压缩的合约代码还是未经压缩的合约代码放入交易中，则节点需要先判断读取到的智能合约的目标机器码是否经过压缩。若是，则先对读取到智能合约的经过压缩的目标机器码进行解压缩，再执行得到的解压缩后的目标机器码，否则可直接执行读取到的未经压缩的目标机器码。
参考前述内容，在一些实施例中，节点可以根据合约调用交易中的账户地址查询合约账户的概要信息(即合约状态)中的合约压缩字段，并根据所述合约压缩字段确定读取到的目标机器码是否经过压缩。
在一些实施例中，在一个智能合约的代码中可以出现调用其他智能合约的语句。具体地，节点在调用第一智能合约的过程中，可从调用第二智能合约的语句中确定第二智能合约的账户地址，以调用第二智能合约。前文已对智能合约的调用做了详尽的介绍，故这里不再展开描述第二智能合约的调用。
应当注意的是，上述有关流程的描述仅仅是为了示例和说明，而不限定本说明书的适用范围。对于本领域技术人员来说，在本说明书的指导下可以对流程进行各种修正和 改变。然而，这些修正和改变仍在本说明书的范围之内。
图5是根据本说明书一些实施例所示的合约部署交易的组成示意图。如图5所示，合约部署交易可以包括以下字段：from、to、value、data、signature。
其中，from字段可放入交易发起方(即合约部署方)的账户地址；to字段为空字段，以指示创建合约账户；value字段可指示待转移(支付)的通证(如gas)数量；data字段可放入合约代码，例如，放入封装合约代码的evm格式文件/wasm格式文件/wasc文件。在一些实施例中，data字段中的智能合约可以是经过压缩的，signature字段可放入数字签名，该数字签名可通过用交易发起方的账户私钥对前述字段组成的消息的摘要进行加密得到。
可以理解，合约更新交易的字段组成是类似的，不同之处在于：to字段可放入更新的智能合约的账户地址，data字段可放入新版本的合约代码。
图6是根据本说明书一些实施例所示的合约调用交易的组成示意图。如图5所示，智能合约调用交易可以包括以下字段：from、to、value、data、signature。
其中，from字段可放入交易发起方(即合约调用方)的账户地址；to字段可放入调用的智能合约的账户地址；value字段可指示待转移(支付)的通证(如gas)数量；data字段可放入调用的智能合约中的函数及其输入参数；signature字段可放入数字签名，该数字签名可通过用交易发起方的账户私钥对前述字段组成的消息的摘要进行加密得到。
可以理解，图5和图6所示的交易组成仅作为示例，在本说明书的指导下可以对智能合约相关的交易组成进行各种变形。另外，交易的各个字段可以具有任意的命名。例如，value字段也可被命名为amount字段。
图7是根据本说明书一些实施例所示的在区块链中部署智能合约的系统的示例性模块图。如图7所示，系统700可以包括第一交易接收模块710和合约部署模块720。
第一交易接收模块710可以用于接收部署智能合约的交易，所述交易包括所述智能合约的一份或多份经过压缩的机器码。
合约部署模块720可以用于创建所述智能合约的账户和账户地址，并在所述智能合约的账户中存储所述一份或多份经过压缩的机器码。
图8是根据本说明书一些实施例所示的在区块链中更新智能合约的系统的示例性模块图。如图8所示，系统800可以包括第二交易接收模块810和合约更新模块820。
第二交易接收模块810可以用于接收更新智能合约的交易，所述交易包括所述智能合约的账户地址和所述智能合约的一份或多份经过压缩的机器码。
合约更新模块820可以用于根据所述智能合约的账户地址，在所述智能合约的账户中存储所述一份或多份经过压缩的机器码。
图9是根据本说明书一些实施例所示的在区块链中调用智能合约的系统的示例性模块图。如图9所示，系统900可以包括第三交易接收模块910、合约代码读取模块920和合约执行模块930。
第三交易接收模块910可以用于接收调用智能合约的交易，所述交易包括所述智能合约的账户地址。
合约代码读取模块920可以用于根据所述账户地址从所述智能合约的账户中读取所述智能合约的经过压缩的目标机器码。
合约执行模块930可以用于对所述经过压缩的目标机器码进行解压缩，并执行得到的解压缩后的目标机器码。
在一些实施例中，在执行第一智能合约代码的过程中，合约执行模块930可以从调用第二智能合约的语句中确定第二智能合约的账户地址，根据所述账户地址从所述第二智能合约的账户中读取所述第二智能合约的经过压缩的目标机器码，对所述经过压缩的目标机器码进行解压缩，并执行得到的解压缩后的目标机器码。
关于上述系统及其模块的更多细节，可以参考图2～6的相关说明。
应当理解，图7～9所示的系统及其模块可以利用各种方式来实现。例如，在一些实施例中，系统及其模块可以通过硬件、软件或者软件和硬件的结合来实现。其中，硬件部分可以利用专用逻辑来实现；软件部分则可以存储在存储器中，由适当的指令执行系统，例如微处理器或者专用设计硬件来执行。本领域技术人员可以理解上述的方法和系统可以使用计算机可执行指令和/或包含在处理器控制代码中来实现，例如在诸如磁盘、CD或DVD-ROM的载体介质、诸如只读存储器(固件)的可编程的存储器或者诸如光学或电子信号载体的数据载体上提供了这样的代码。本说明书的系统及其模块不仅可以有诸如超大规模集成电路或门阵列、诸如逻辑芯片、晶体管等的半导体、或者诸如现场可编程门阵列、可编程逻辑设备等的可编程硬件设备的硬件电路实现，也可以用例如由各种类型的处理器所执行的软件实现，还可以由上述硬件电路和软件的结合(例如，固件)来实现。
需要注意的是，以上对于系统及其模块的描述，仅为描述方便，并不能把本说明书限制在所举实施例范围之内。可以理解，对于本领域的技术人员来说，在了解系统的原理后，可能在不背离这一原理的情况下，对各个模块进行任意组合，或者构成子系统与其他模块连接。例如，在一些实施例中，合约代码读取模块920和合约执行模块930可以是两个模块，也可以合并为一个模块。诸如此类的变形，均在本说明书的保护范围之内。
本说明书实施例可能带来的有益效果包括但不限于：(1)将机器码上链以供调用，可以大大提升智能合约的执行效率；(2)将智能合约的机器码压缩后再上链，可以极大地节约部署智能合约耗费的存储成本、通证以及网络传输带宽。需要说明的是，不同 实施例可能产生的有益效果不同，在不同的实施例里，可能产生的有益效果可以是以上任意一种或几种的组合，也可以是其他任何可能获得的有益效果。
上文已对基本概念做了描述，显然，对于本领域技术人员来说，上述详细披露仅仅作为示例，而并不构成对本说明书实施例的限定。虽然此处并没有明确说明，本领域技术人员可能会对本说明书实施例进行各种修改、改进和修正。该类修改、改进和修正在本说明书实施例中被建议，所以该类修改、改进、修正仍属于本说明书示范实施例的精神和范围。
同时，本说明书使用了特定词语来描述本说明书的实施例。如“一个实施例”、“一实施例”、和/或“一些实施例”意指与本说明书至少一个实施例相关的某一特征、结构或特点。因此，应强调并注意的是，本说明书中在不同位置两次或多次提及的“一实施例”或“一个实施例”或“一个替代性实施例”并不一定是指同一实施例。此外，本说明书的一个或多个实施例中的某些特征、结构或特点可以进行适当的组合。
此外，本领域技术人员可以理解，本说明书实施例的各方面可以通过若干具有可专利性的种类或情况进行说明和描述，包括任何新的和有用的工序、机器、产品或物质的组合，或对他们的任何新的和有用的改进。相应地，本说明书实施例的各个方面可以完全由硬件执行、可以完全由软件(包括固件、常驻软件、微码等)执行、也可以由硬件和软件组合执行。以上硬件或软件均可被称为“数据块”、“模块”、“引擎”、“单元”、“组件”或“系统”。此外，本说明书实施例的各方面可能表现为位于一个或多个计算机可读介质中的计算机产品，该产品包括计算机可读程序编码。
计算机存储介质可能包含一个内含有计算机程序编码的传播数据信号，例如在基带上或作为载波的一部分。该传播信号可能有多种表现形式，包括电磁形式、光形式等，或合适的组合形式。计算机存储介质可以是除计算机可读存储介质之外的任何计算机可读介质，该介质可以通过连接至一个指令执行系统、装置或设备以实现通讯、传播或传输供使用的程序。位于计算机存储介质上的程序编码可以通过任何合适的介质进行传播，包括无线电、电缆、光纤电缆、RF、或类似介质，或任何上述介质的组合。
本说明书实施例各部分操作所需的计算机程序编码可以用任意一种或多种程序语言编写，包括面向对象编程语言如Java、Scala、Smalltalk、Eiffel、JADE、Emerald、C++、C#、VB.NET、Python等，常规程序化编程语言如C语言、VisualBasic、Fortran2003、Perl、COBOL2002、PHP、ABAP，动态编程语言如Python、Ruby和Groovy，或其他编程语言等。该程序编码可以完全在用户计算机上运行、或作为独立的软件包在用户计算机上运行、或部分在用户计算机上运行部分在远程计算机运行、或完全在远程计算机或处理设备上运行。在后种情况下，远程计算机可以通过任何网络形式与用户计算机连接，比如局域网(LAN)或广域网(WAN)，或连接至外部计算机(例如通过因特网)，或在云计算环境中，或作为服务使用如软件即服务(SaaS)。
此外，除非权利要求中明确说明，本说明书实施例所述处理元素和序列的顺序、数字字母的使用、或其他名称的使用，并非用于限定本说明书实施例流程和方法的顺序。尽管上述披露中通过各种示例讨论了一些目前认为有用的发明实施例，但应当理解的是，该类细节仅起到说明的目的，附加的权利要求并不仅限于披露的实施例，相反，权利要求旨在覆盖所有符合本说明书实施例实质和范围的修正和等价组合。例如，虽然以上所描述的系统组件可以通过硬件设备实现，但是也可以只通过软件的解决方案得以实现，如在现有的处理设备或移动设备上安装所描述的系统。
同理，应当注意的是，为了简化本说明书实施例披露的表述，从而帮助对一个或多个发明实施例的理解，前文对本说明书实施例的描述中，有时会将多种特征归并至一个实施例、附图或对其的描述中。但是，这种披露方法并不意味着本说明书实施例对象所需要的特征比权利要求中提及的特征多。实际上，实施例的特征要少于上述披露的单个实施例的全部特征。
针对本说明书引用的每个专利、专利申请、专利申请公开物和其他材料，如文章、书籍、说明书、出版物、文档等，特此将其全部内容并入本说明书作为参考。与本说明书内容不一致或产生冲突的申请历史文件除外，对本说明书权利要求最广范围有限制的文件(当前或之后附加于本说明书中的)也除外。需要说明的是，如果本说明书附属材料中的描述、定义、和/或术语的使用与本说明书所述内容有不一致或冲突的地方，以本说明书的描述、定义和/或术语的使用为准。
最后，应当理解的是，本说明书中所述实施例仅用以说明本说明书实施例的原则。其他的变形也可能属于本说明书实施例的范围。因此，作为示例而非限制，本说明书实施例的替代配置可视为与本说明书的教导一致。相应地，本说明书的实施例不仅限于本说明书明确介绍和描述的实施例。

Claims (33)

  1. 一种在区块链中部署智能合约的方法，其中，包括：
    接收部署智能合约的交易，所述交易包括所述智能合约的一份或多份经过压缩的机器码；
    创建所述智能合约的账户和账户地址，并在所述智能合约的账户中存储所述一份或多份经过压缩的机器码。
  2. 如权利要求1所述的方法，其中，所述交易包括封装所述智能合约的一份或多份经过压缩的机器码的合约代码文件，所述合约代码文件还包括所述智能合约的未经压缩的字节码；
    所述在所述智能合约的账户中存储所述一份或多份经过压缩的机器码，包括：
    在所述智能合约的账户中存储所述合约代码文件。
  3. 如权利要求2所述的方法，其中，还包括：
    设置所述智能合约的账户的概要信息，所述概要信息包括所述合约代码文件的唯一标识，所述合约代码文件的唯一标识被设置为所述合约代码文件的哈希值。
  4. 如权利要求2所述的方法，其中，所述合约代码文件还包括所述智能合约的压缩信息，所述压缩信息指示所述合约代码文件中的智能合约的机器码是经过压缩的和/或用于压缩所述合约代码文件中的智能合约的机器码的算法。
  5. 如权利要求1或2所述的方法，其中，所述智能合约为EVM合约或WASM合约。
  6. 如权利要求1或2所述的方法，其中，所述机器码通过对所述智能合约的源代码或中间代码进行提前编译得到。
  7. 如权利要求1或2所述的方法，其中，还包括：
    设置所述智能合约的账户的概要信息，所述概要信息包括合约压缩字段，所述合约压缩字段被设置为指示所述智能合约的账户中的机器码是经过压缩的。
  8. 一种在区块链中部署智能合约的装置，其中，包括处理器和存储设备，所述存储设备用于存储指令，当所述处理器执行指令时，实现如权利要求1～7中任一项所述的方法。
  9. 一种在区块链中部署智能合约的系统，其中，包括第一交易接收模块和合约部署模块；
    所述第一交易接收模块接收部署智能合约的交易，所述交易包括所述智能合约的一份或多份经过压缩的机器码；
    所述合约部署模块用于创建所述智能合约的账户和账户地址，并在所述智能合约的账户中存储所述一份或多份经过压缩的机器码。
  10. 一种在区块链中更新智能合约的方法，其中，包括：
    接收更新智能合约的交易，所述交易包括所述智能合约的账户地址和所述智能合约的一份或多份经过压缩的机器码；
    根据所述智能合约的账户地址，在所述智能合约的账户中存储所述一份或多份经过压缩的机器码。
  11. 如权利要求10所述的方法，其中，所述交易包括封装所述智能合约的一份或多份经过压缩的机器码的合约代码文件，所述合约代码文件还包括所述智能合约的未经压缩的字节码；
    所述在所述智能合约的账户中存储所述一份或多份经过压缩的机器码，包括：
    在所述智能合约的账户中存储所述合约代码文件。
  12. 如权利要求11所述的方法，其中，还包括：
    更新所述智能合约的账户的概要信息，所述概要信息包括所述合约代码文件的唯一标识，所述合约代码文件的唯一标识被设置为所述合约代码文件的哈希值。
  13. 如权利要求11所述的方法，其中，所述合约代码文件还包括所述智能合约的压缩信息，所述压缩信息指示所述合约代码文件中的智能合约的机器码是经过压缩的和/或用于压缩所述合约代码文件中的智能合约的机器码的算法。
  14. 如权利要求10或11所述的方法，其中，所述智能合约为EVM合约或WASM合约。
  15. 如权利要求10或11所述的方法，其中，所述机器码通过对所述智能合约的源代码或中间代码进行编译得到。
  16. 如权利要求10或11所述的方法，其中，还包括：
    更新所述智能合约的账户的概要信息，所述概要信息包括合约压缩字段，所述合约压缩字段被设置为指示所述智能合约的账户中的机器码是经过压缩的。
  17. 一种在区块链中更新智能合约的装置，其中，包括处理器和存储设备，所述存储设备用于存储指令，当所述处理器执行指令时，实现如权利要求10～16中任一项所述的方法。
  18. 一种在区块链中更新智能合约的系统，其中，包括第二交易接收模块和合约更新模块；
    所述第二交易接收模块用于接收更新智能合约的交易，所述交易包括所述智能合约的账户地址和所述智能合约的一份或多份经过压缩的机器码；
    所述合约更新模块用于根据所述智能合约的账户地址，在所述智能合约的账户中存储所述一份或多份经过压缩的机器码。
  19. 一种在区块链中调用智能合约的方法，其中，包括：
    接收调用智能合约的交易，所述交易包括所述智能合约的账户地址；
    根据所述账户地址从所述智能合约的账户中读取所述智能合约的经过压缩的目标机器码；
    对所述经过压缩的目标机器码进行解压缩，并执行得到的解压缩后的目标机器码。
  20. 如权利要求19所述的方法，其中，所述根据所述账户地址从所述智能合约的账户中读取所述智能合约的经过压缩的目标机器码之前，所述方法还包括：
    根据所述账户地址查询所述智能合约的账户的概要信息中的合约压缩字段，并根据该字段确定读取到的目标机器码是经过压缩的。
  21. 如权利要求19所述的方法，其中，所述根据所述账户地址从所述智能合约的账户中读取所述智能合约的经过压缩的目标机器码，包括：
    根据所述账户地址从所述智能合约的账户中读取合约代码文件，所述合约代码文件包括所述智能合约的一份或多份经过压缩的机器码以及所述智能合约的未经压缩的字节码；
    从所述一份或多份经过压缩的机器码中确定所述经过压缩的目标机器码。
  22. 如权利要求21所述的方法，其中，所述合约代码文件具有唯一标识，所述唯一标识被设置为所述合约代码文件的哈希值，所述智能合约的账户具有包含所述合约代码文件的唯一标识在内的概要信息；所述根据所述账户地址从所述智能合约的账户中读取合约代码文件，包括：
    根据所述账户地址查询所述智能合约的账户的概要信息中的所述合约代码文件的唯一标识，并根据所述唯一标识读取所述合约代码文件。
  23. 如权利要求21所述的方法，其中，所述合约代码文件还包括所述智能合约的压缩信息，所述压缩信息指示所述合约代码文件中的智能合约的机器码是经过压缩的和/或用于压缩所述合约代码文件中的智能合约的机器码的算法；所述对所述经过压缩的目标机器码进行解压缩，包括：
    根据所述压缩信息对所述经过压缩的目标机器码进行解压缩。
  24. 如权利要求21所述的方法，其中，还包括：
    执行所述未经压缩的字节码；
    比较所述字节码的执行结果和所述目标机器码的执行结果。
  25. 一种在区块链中调用智能合约的装置，其中，包括处理器和存储设备，所述存储设备用于存储指令，当所述处理器执行指令时，实现如权利要求19～24中任一项所述的方法。
  26. 一种在区块链中调用智能合约的系统，其中，包括第三交易接收模块、合约代码读取模块和合约执行模块；
    所述第三交易接收模块用于接收调用智能合约的交易，所述交易包括所述智能合约的账户地址；
    所述合约代码读取模块用于根据所述账户地址从所述智能合约的账户中读取所述智能合约的经过压缩的目标机器码；
    所述合约执行模块用于对所述经过压缩的目标机器码进行解压缩，并执行得到的解压缩后的目标机器码。
  27. 一种在区块链中调用智能合约的方法，其中，包括：
    在调用第一智能合约的过程中：
    从调用第二智能合约的语句中确定第二智能合约的账户地址；
    根据所述账户地址从所述第二智能合约的账户中读取所述第二智能合约的经过压缩的目标机器码；
    对所述经过压缩的目标机器码进行解压缩，并执行得到的解压缩后的目标机器码。
  28. 如权利要求27所述的方法，其中，所述根据所述账户地址从所述第二智能合约的账户中读取所述第二智能合约的经过压缩的目标机器码之前，所述方法还包括：
    根据所述账户地址查询所述第二智能合约的账户的概要信息中的合约压缩字段，并根据该字段确定读取到的目标机器码是经过压缩的。
  29. 如权利要求27所述的方法，其中，所述根据所述账户地址从所述第二智能合约的账户中读取所述第二智能合约的经过压缩的目标机器码，包括：
    根据所述账户地址从所述第二智能合约的账户中读取合约代码文件，所述合约代码文件包括所述第二智能合约的一份或多份经过压缩的机器码以及所述第二智能合约的未经压缩的字节码；
    从所述一份或多份经过压缩的机器码中确定所述经过压缩的目标机器码。
  30. 如权利要求29所述的方法，其中，所述合约代码文件具有唯一标识，所述唯一标识被设置为所述合约代码文件的哈希值，所述第二智能合约的账户具有包含所述合约代码文件的唯一标识在内的概要信息；所述根据所述账户地址从所述第二智能合约的账户中读取合约代码文件，包括：
    根据所述账户地址查询所述第二智能合约的账户的概要信息中的所述合约代码文件的唯一标识，并根据所述唯一标识读取所述合约代码文件。
  31. 如权利要求29所述的方法，其中，所述合约代码文件还包括所述第二智能合约的压缩信息，所述压缩信息指示所述合约代码文件中的第二智能合约的机器码是经过压缩的和/或用于压缩所述合约代码文件中的第二智能合约的机器码的算法；所述对所述经过压缩的目标机器码进行解压缩，包括：
    根据所述压缩信息对所述经过压缩的目标机器码进行解压缩。
  32. 一种在区块链中调用智能合约的装置，其中，包括处理器和存储设备，所述存储设备用于存储指令，当所述处理器执行指令时，实现如权利要求27～31中任一项所述的方法。
  33. 一种在区块链中调用智能合约的系统，其中，所述系统用于在调用第一智能合约的过程中：
    从调用第二智能合约的语句中确定第二智能合约的账户地址；
    根据所述账户地址从所述第二智能合约的账户中读取所述第二智能合约的经过压缩的目标机器码；
    对所述经过压缩的目标机器码进行解压缩，并执行得到的解压缩后的目标机器码。
PCT/CN2022/070464 2020-06-05 2022-01-06 一种在区块链中部署、更新、调用智能合约的方法 WO2022148390A1 (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN202010505361 2020-06-05
CN202110030424.2A CN112835975B (zh) 2020-06-05 2021-01-11 一种在区块链中部署、更新、调用智能合约的方法
CN202110030424.2 2021-01-11

Publications (1)

Publication Number Publication Date
WO2022148390A1 true WO2022148390A1 (zh) 2022-07-14

Family

ID=75929579

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/070464 WO2022148390A1 (zh) 2020-06-05 2022-01-06 一种在区块链中部署、更新、调用智能合约的方法

Country Status (2)

Country Link
CN (1) CN112835975B (zh)
WO (1) WO2022148390A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115021945A (zh) * 2022-08-08 2022-09-06 四块科技(深圳)有限公司 区块链交易处理方法和系统
CN116700628A (zh) * 2023-08-01 2023-09-05 腾讯科技（深圳）有限公司 区块链数据处理方法、装置、计算机设备和存储介质

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112835975B (zh) * 2020-06-05 2023-09-29 支付宝(杭州)信息技术有限公司 一种在区块链中部署、更新、调用智能合约的方法
CN113256423A (zh) * 2021-06-11 2021-08-13 武汉龙津科技有限公司 通证分配触发设置方法、装置、电子设备及存储介质
CN113721947A (zh) * 2021-07-21 2021-11-30 杭州溪塔科技有限公司 一种区块链合约原地址升级的方法和装置
US12079606B2 (en) * 2022-09-21 2024-09-03 Circle Internet Financial Limited Smart contract distribution infrastructure

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012141871A1 (en) * 2011-04-11 2012-10-18 Marvell World Trade Ltd. Method for compression and real-time decompression of executable code
CN109710384A (zh) * 2018-12-29 2019-05-03 杭州趣链科技有限公司 一种安全的Java智能合约解释执行引擎及方法
CN109711839A (zh) * 2018-12-13 2019-05-03 平安科技（深圳）有限公司 基于数据压缩的区块链存储方法、装置、设备和存储介质
CN110147202A (zh) * 2019-05-15 2019-08-20 杭州云象网络技术有限公司 一种减少区块链智能合约代码存储体积的方法
US20200175002A1 (en) * 2019-04-30 2020-06-04 Alibaba Group Holding Limited Blockchain-based data compression and searching
CN111459895A (zh) * 2020-03-31 2020-07-28 杭州云象网络技术有限公司 一种区块链数据分级压缩与存储方法及系统
CN111768184A (zh) * 2020-08-31 2020-10-13 支付宝(杭州)信息技术有限公司 一种执行智能合约的方法及区块链节点
CN111815330A (zh) * 2020-08-31 2020-10-23 支付宝(杭州)信息技术有限公司 一种部署智能合约的方法、区块链节点和存储介质
CN112835975A (zh) * 2020-06-05 2021-05-25 支付宝(杭州)信息技术有限公司 一种在区块链中部署、更新、调用智能合约的方法

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014201059A1 (en) * 2013-06-10 2014-12-18 Certimix, Llc Secure storing and offline transfering of digitally transferable assets
US20160378452A1 (en) * 2015-06-29 2016-12-29 Mediatek Inc. Policy-Based Compression of Machine Code Generated by a Virtual Machine
US20170031940A1 (en) * 2015-07-31 2017-02-02 Netapp, Inc. Compression file structure
CN108563796A (zh) * 2018-05-04 2018-09-21 蔷薇信息技术有限公司 区块链的数据压缩处理方法、装置及电子设备
CN108765158B (zh) * 2018-05-31 2020-11-24 杭州溪塔科技有限公司 一种基于区块链的智能合约引擎系统及其合约执行方法
CN109445773A (zh) * 2018-09-27 2019-03-08 深圳点猫科技有限公司 一种基于编程语言提升浏览器性能的方法以及电子设备
PL3542494T3 (pl) * 2018-12-29 2021-08-23 Advanced New Technologies Co., Ltd. System i sposób realizacji umowy wewnętrznej w łańcuchu bloków
CN110060158B (zh) * 2019-03-07 2020-06-09 阿里巴巴集团控股有限公司 基于变长编码的智能合约执行方法和装置
CN110309117A (zh) * 2019-07-08 2019-10-08 匿名科技(重庆)集团有限公司 一种高可用区块链存储方法

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012141871A1 (en) * 2011-04-11 2012-10-18 Marvell World Trade Ltd. Method for compression and real-time decompression of executable code
CN109711839A (zh) * 2018-12-13 2019-05-03 平安科技（深圳）有限公司 基于数据压缩的区块链存储方法、装置、设备和存储介质
CN109710384A (zh) * 2018-12-29 2019-05-03 杭州趣链科技有限公司 一种安全的Java智能合约解释执行引擎及方法
US20200175002A1 (en) * 2019-04-30 2020-06-04 Alibaba Group Holding Limited Blockchain-based data compression and searching
CN110147202A (zh) * 2019-05-15 2019-08-20 杭州云象网络技术有限公司 一种减少区块链智能合约代码存储体积的方法
CN111459895A (zh) * 2020-03-31 2020-07-28 杭州云象网络技术有限公司 一种区块链数据分级压缩与存储方法及系统
CN112835975A (zh) * 2020-06-05 2021-05-25 支付宝(杭州)信息技术有限公司 一种在区块链中部署、更新、调用智能合约的方法
CN111768184A (zh) * 2020-08-31 2020-10-13 支付宝(杭州)信息技术有限公司 一种执行智能合约的方法及区块链节点
CN111815330A (zh) * 2020-08-31 2020-10-23 支付宝(杭州)信息技术有限公司 一种部署智能合约的方法、区块链节点和存储介质

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
WANG, SHOU-DAO; JIANG, YU-MING; HU, DA-SHA: "Smart Contract Compression Storage Method Based on Blockchain", XIANDAI JISUANJI (ZHUANYE BAN)/ MODERN COMPUTER (PROFESSIONAL EDITION), XIANDAI JISUANJI ZAZHISHE, CHINA, no. 9, 31 March 2019 (2019-03-31), China , pages 42 - 46, XP009523689, ISSN: 1007-1423, DOI: 10.3969/j.issn.1007-1423.2019.09.009 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115021945A (zh) * 2022-08-08 2022-09-06 四块科技(深圳)有限公司 区块链交易处理方法和系统
CN115021945B (zh) * 2022-08-08 2022-11-08 四块科技(深圳)有限公司 区块链交易处理方法和系统
CN116700628A (zh) * 2023-08-01 2023-09-05 腾讯科技（深圳）有限公司 区块链数据处理方法、装置、计算机设备和存储介质
CN116700628B (zh) * 2023-08-01 2024-02-02 腾讯科技（深圳）有限公司 区块链数据处理方法、装置、计算机设备和存储介质

Also Published As

Publication number Publication date
CN112835975A (zh) 2021-05-25
CN112835975B (zh) 2023-09-29

Similar Documents

Publication Publication Date Title
WO2022148390A1 (zh) 一种在区块链中部署、更新、调用智能合约的方法
JP6856749B2 (ja) ブロックチェーン上のネイティブ契約を実施するためのシステムおよび方法
CN109710384B (zh) 一种安全的Java智能合约解释执行引擎及方法
CN108027722B (zh) 在编译和部署中动态更新应用
US10367822B2 (en) Restrictive access control for modular reflection
US10146515B1 (en) Live code updates
US11733985B2 (en) Accessing a migrated member in an updated type
CN111095198B (zh) 用于数据处理的系统和方法
TWI536263B (zh) 將作業系統之原始應用程式介面投射至其它程式語言
US20160232017A1 (en) System and Method for Reloading Constructors
US10303449B2 (en) Compiling non-native constants
CN111179086B (zh) 一种基于WebAssembly的智能合约虚拟机
WO2024045382A1 (zh) 区块链中实现反射机制
CN106909441B (zh) 一种基于jvm的磁盘直接i/o访问的方法
US10310827B2 (en) Flow-based scoping
WO2022110775A1 (zh) 一种无服务容器启动方法及相关设备
CN115629971A (zh) 一种应用的开发系统和开发方法
US20170083298A1 (en) Resilient format for distribution of ahead-of-time compiled code components
CN117056317B (zh) 数据处理方法、装置、设备及计算机可读存储介质
EP4394601A1 (en) Systems, methods, and apparatus for intermediary representations of workflows for computational devices
US20240220266A1 (en) Systems, methods, and apparatus for intermediary representations of workflows for computational devices
CN118295638A (zh) 一种区块链服务生成方法及相关设备
CN114185556A (zh) 一种智能合约部署方法、装置、设备以及存储介质
CN117785511A (zh) 功能数据处理的方法及装置、存储介质及电子设备

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22736552

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22736552

Country of ref document: EP

Kind code of ref document: A1