WO2019024674A1 - 智能合约处理方法及装置 - Google Patents

智能合约处理方法及装置 Download PDF

Info

Publication number
WO2019024674A1
WO2019024674A1 PCT/CN2018/095784 CN2018095784W WO2019024674A1 WO 2019024674 A1 WO2019024674 A1 WO 2019024674A1 CN 2018095784 W CN2018095784 W CN 2018095784W WO 2019024674 A1 WO2019024674 A1 WO 2019024674A1
Authority
WO
WIPO (PCT)
Prior art keywords
class file
smart contract
request
call request
deployment
Prior art date
Application number
PCT/CN2018/095784
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 众安信息技术服务有限公司
Priority to KR1020197019035A priority Critical patent/KR20190107664A/ko
Priority to SG11201907111QA priority patent/SG11201907111QA/en
Priority to JP2019524456A priority patent/JP2019536153A/ja
Priority to AU2018310287A priority patent/AU2018310287A1/en
Publication of WO2019024674A1 publication Critical patent/WO2019024674A1/zh
Priority to US16/460,202 priority patent/US20190324772A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44589—Program code verification, e.g. Java bytecode verification, proof-carrying code
    • 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
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • 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/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405—Establishing or using transaction specific rules
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0637—Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Definitions

  • the invention belongs to the field of computer data processing, and in particular relates to a smart contract processing method and device.
  • a smart contract is a set of commitments defined in digital form on which contract participants can implement these promised agreements.
  • the smart contract itself and the contract execution process can be observed, and the process and judgment of the contract execution can be verified.
  • the smart contract itself and the contract-related information can only be contacted by the relevant contract party, and the relevant information will be exposed to third-party review when a conflict occurs.
  • Blockchain technology is a decentralized peer-to-peer network that combines cryptographic principles with consensus mechanisms to ensure data coherence and persistence across distributed nodes, enabling instant verification, traceability, difficulty in tampering, and unmasking of information. This creates a shared, efficient, and secure shared value system.
  • Smart contracts are decentralized application technologies that are implemented by blockchain technology to implement complex functions. The smart contract is written in a high-level language, compiled by the corresponding compiler to generate the code that the blockchain can recognize and execute, deployed in the blockchain, and provides corresponding functions.
  • a system or module used to execute a smart contract generally referred to as the execution engine of a smart contract.
  • the existing intelligent contract execution engine is mainly realized by creating a scripting language and its interpreter.
  • the present invention is directed to the above problems, and proposes a smart contract processing method and apparatus.
  • a method for processing a smart contract in a multi-node system includes: determining a class file corresponding to the smart contract based on a call request for a smart contract to be invoked; The class file executes the smart contract; wherein the class file is pre-compiled based on program logic of the smart contract.
  • the class file includes an instruction and a counter corresponding to the instruction; wherein the executing the smart contract based on the class file comprises: performing execution of the instruction by using the counter The number of times is counted, and when the number of executions is greater than the preset number of times, the execution of the instruction is stopped.
  • the class file includes a plurality of the instructions, each of the instructions is provided with a corresponding weight; wherein, the value of the weight is larger, the instruction corresponding to the weight The fewer the preset times.
  • the determining, according to the calling request for the smart contract to be invoked, the class file corresponding to the smart contract includes: searching, according to the calling request, a class file library corresponding to the smart contract Class file.
  • the searching for a class file corresponding to the smart contract to be invoked in the class file library based on the calling request includes: acquiring, in the calling request, the smart contract for indicating the smart contract Identifying information; and searching for a class file corresponding to the smart contract in the class file library according to the identification information.
  • the determining, according to the calling request for the smart contract to be invoked, the class file corresponding to the smart contract to be invoked includes: indicating, according to the calling request, an identifier for indicating the smart contract The information generates the class file that satisfies the call request.
  • the executing the smart contract based on the class file comprises: instantiating the class file, and determining functions and parameters in the call request; and based on the instantiated The class file and the functions and parameters are used to execute the smart contract.
  • the method for processing the smart contract in the multi-node system before determining the class file corresponding to the smart contract based on the calling request for the smart contract to be invoked, the method for processing the smart contract in the multi-node system further includes: It is determined that the call request is legal.
  • the determining the call request legally includes: agreeing on a format of the call request, and determining that the call request is legal when all nodes consider that the format of the call request is legal.
  • the class file is pre-deployed in the multi-node system, wherein the deployment process of the class file includes: loading the class file to be deployed by a class loader; When the non-deterministic class and/or non-deterministic function is not included in the class file, the class file is deployed to form a class file library.
  • the process of deploying the class file further includes: setting and executing in the class file when determining that the class file does not include a non-deterministic class and/or a non-deterministic function; A corresponding counter, wherein the counter is configured to count the number of executions of the instruction during execution of the smart contract.
  • the method for processing a smart contract in a multi-node system further comprises: determining that a deployment request for deploying the class file is legal.
  • the determining that the deployment request of the class file is legally includes: agreeing on a format of the deployment request, and determining, when all nodes consider that the format of the deployment request is legal The call request is legal.
  • an apparatus for processing a smart contract in a multi-node system comprising: a determining module configured to determine the smart contract based on a call request for a smart contract to be invoked a corresponding class file; and an execution module configured to execute the smart contract to be invoked based on a class file corresponding to the smart contract to be invoked; wherein the class file is based on a program logic of the smart contract to be invoked in advance Compiled.
  • the class file includes an instruction and a counter corresponding to the instruction, wherein the execution module is further configured to: count, by using the counter, the number of executions of the instruction, When the number of executions is greater than the preset number of times, the execution of the instruction is stopped.
  • the class file includes a plurality of the instructions, each of the instructions is provided with a corresponding weight; wherein, the value of the weight is larger, the instruction corresponding to the weight The fewer the preset times.
  • the determining module is further configured to: look up a class file corresponding to the smart contract in a class file library based on the call request.
  • the determining module is further configured to: obtain identifier information used to indicate the smart contract in the call request, and search for and in the class file library according to the identifier information.
  • the class file corresponding to the smart contract is further configured to: obtain identifier information used to indicate the smart contract in the call request, and search for and in the class file library according to the identifier information.
  • the apparatus for processing a smart contract in a multi-node system further includes: a generating module, configured to generate, according to the identifier information used to indicate the smart contract in the call request The class file of the call request.
  • the execution module is further configured to: instantiate the class file, and determine a function and a parameter in an invocation request to invoke the smart contract; and based on the instantiated class The file and the function and parameters execute the smart contract invoked by the call request.
  • the apparatus for processing a smart contract in a multi-node system further comprises: a first verification module configured to determine the smart contract based on a call request for a smart contract to be invoked Before the corresponding class file, it is determined that the calling request of the smart contract is legal.
  • the first verification module is further configured to: determine a format of the call request, and determine that the call request is legal when all nodes consider that the format of the call request is legal.
  • the apparatus for processing a smart contract in a multi-node system further includes: a deployment module configured to load the class file to be deployed by a class loader; and when determining the When non-deterministic classes and/or non-deterministic functions are not included in the class file, the class files are deployed to form a class file library.
  • the deployment module is further configured to: when determining that the class file does not include a non-deterministic class and/or a non-deterministic function, set a corresponding to the instruction in the class file. a counter, wherein the counter is configured to count the number of executions of the instruction during execution of the smart contract.
  • the deployment module is further configured to deploy the class file at a local node or in a storage device communicatively coupled to the local node to form a class file library.
  • the apparatus for processing a smart contract in a multi-node system further includes: a second verification module, configured to determine the deployment before the deployment module deploys the class file The deployment request for the class file is legal.
  • the second verification module is further configured to: determine a format of the deployment request, and determine that the call request is legal when all nodes consider that the format of the deployment request is legal.
  • a method of deploying a smart contract in a multi-node system comprising: obtaining a deployment request including a smart contract class file, wherein the deployment request includes a class file, the class The file is pre-compiled based on program logic of the smart contract to be deployed; and when it is determined that the class file does not include a non-deterministic class and/or a non-deterministic function, the class file is deployed on the multi-node In the system.
  • the process of deploying the class file further includes: setting and executing in the class file when determining that the class file does not include a non-deterministic class and/or a non-deterministic function; A corresponding counter, wherein the counter is configured to count the number of executions of the instruction during execution of the smart contract.
  • the class file is deployed at a local node or in a storage device communicatively coupled to the local node to form a class file library.
  • the method for deploying the smart contract in the multi-node system further comprises: determining that the deployment request for deploying the class file is legal.
  • the determining that the deployment request of the class file is legally includes: agreeing on a format of the deployment request, and determining, when all nodes consider that the format of the deployment request is legal The call request is legal.
  • an apparatus for deploying a smart contract in a multi-node system comprising: an acquisition module configured to obtain a deployment request, wherein the deployment request includes a class file, the class file Pre-compiled based on program logic of the smart contract to be deployed; and a deployment execution module configured to deploy the class file when it is determined that the class file does not include a non-deterministic class and/or a non-deterministic function In the multi-node system.
  • the deployment execution module is further configured to: when determining that the class file does not include a non-deterministic class and/or a non-deterministic function, set a correspondence with the instruction in the class file. And a counter, wherein the counter is configured to count the number of executions of the instruction during execution of the smart contract.
  • the deployment execution module is further configured to deploy the class file at a local node or in a storage device communicatively coupled to the local node to form a class file library.
  • the third verification module is configured to determine that the deployment request for deploying the class file is legal before the class file is deployed.
  • the third verification module is further configured to: determine a format of the deployment request, and determine that the call request is legal when all nodes consider that the format of the deployment request is legal.
  • a computer apparatus comprising a memory, a processor, and a computer program stored on the memory for execution by the processor, wherein the processor executes the computer program
  • a computer readable storage medium having stored thereon a computer program, wherein the computer program, when executed by a processor, implements a multi-node as described above
  • the steps of a method of processing a smart contract in a system, or any of the methods described above for deploying a smart contract in a multi-node system are also provided.
  • FIG. 1 is a schematic flowchart diagram of a method for processing a smart contract in a multi-node system according to an embodiment of the present invention.
  • FIG. 2 is a schematic flowchart diagram of executing a smart contract to be invoked in a method for processing a smart contract in a multi-node system according to an embodiment of the present invention.
  • FIG. 3 is a schematic flowchart diagram of a method for processing a smart contract in a multi-node system according to another embodiment of the present invention.
  • FIG. 4 is a schematic flowchart diagram of a method for processing a smart contract in a multi-node system according to another embodiment of the present invention.
  • FIG. 5 is a schematic flowchart diagram of a method for processing a smart contract in a multi-node system according to another embodiment of the present invention.
  • FIG. 6 is a flowchart of a method for calling a smart contract provided by an embodiment of the invention.
  • FIG. 7 is a schematic structural diagram of an apparatus for processing a smart contract in a multi-node system according to an embodiment of the present invention.
  • FIG. 8 is a schematic structural diagram of an apparatus for processing a smart contract in a multi-node system according to another embodiment of the present invention.
  • FIG. 9 is a schematic structural diagram of an apparatus for processing a smart contract in a multi-node system according to another embodiment of the present invention.
  • FIG. 10 is a schematic structural diagram of an apparatus for processing a smart contract in a multi-node system according to another embodiment of the present invention.
  • FIG. 11 is a schematic structural diagram of an apparatus for processing a smart contract in a multi-node system according to an embodiment of the present invention.
  • FIG. 12 is a schematic flowchart diagram of a method for deploying a smart contract in a multi-node system according to an embodiment of the present invention.
  • FIG. 13 is a schematic flowchart diagram of a method for deploying a smart contract in a multi-node system according to another embodiment of the present invention.
  • FIG. 14 is a schematic flowchart diagram of a method for deploying a smart contract in a multi-node system according to another embodiment of the present invention.
  • FIG. 15a is a flowchart of a method for deploying a smart contract according to an embodiment of the present invention.
  • FIG. 15b is a schematic structural diagram of a class file according to an embodiment of the present invention.
  • FIG. 16 is a schematic structural diagram of an apparatus for deploying a smart contract in a multi-node system according to an embodiment of the present invention.
  • FIG. 17 is a schematic structural diagram of an apparatus for deploying a smart contract in a multi-node system according to another embodiment of the present invention.
  • the Java language is a high-level programming language.
  • the class file is a compiled product of the Java source code and carries the specific program logic.
  • the environment in which the Java program runs is called the Java Virtual Machine (JVM).
  • the Java virtual machine provides a Class Loading mechanism, through which the Java runtime class files can be managed.
  • the functional modules that implement this mechanism are called Class Loaders.
  • a deterministic function means that the deterministic function always returns the same value each time a particular set of input values is used; correspondingly, if a different result is returned, the function is a non-deterministic function.
  • FIG. 1 is a schematic flowchart diagram of a method for processing a smart contract in a multi-node system according to an embodiment of the present invention. As shown in FIG. 1, the method includes the following steps:
  • Step 101 Determine a class file corresponding to the smart contract based on a call request for a smart contract to be invoked. This class of files is precompiled based on the program logic of the smart contract to be called.
  • Step 102 Perform a smart contract to be invoked based on the class file.
  • the specific execution process may include: first instantiating the class file, and determining functions and parameters in the calling request of the smart contract; then executing the smart contract invoked by the calling request based on the instantiated class file and the function and parameters .
  • the embodiment of the present invention actually provides a smart contract execution system (execution engine) based on a Java virtual machine and a flow and an algorithm corresponding to the system.
  • a smart contract execution system execution engine
  • execution engine execution engine
  • the blockchain platform of the execution system it is possible to support the development of smart contracts using the Java language.
  • all languages also known as JVM languages
  • JVM languages running on the Java virtual machine
  • Scala Scala
  • Groovy Jython
  • the program logic of the smart contract is compiled into a class file based on the Java language
  • the development of smart contracts based on the Java language eliminates the need to develop additional compilers and interpreters. Developers can use the Java language feature to develop and use blockchain technology, easy to access to meet engineering-level applications, easy to use, and suitable for marketing.
  • the content of the class file actually includes the program logic content of the smart contract, so in the description of some embodiments later, there is no concept of the class file and the smart contract.
  • the concept is strictly logically distinguished. For example, when a call, execution, and deployment of a smart contract is to be implemented, the call, execution, and deployment of the class file are actually performed.
  • a class file can include instructions and counters corresponding to the instructions.
  • FIG. 2 when executing the smart contract to be invoked, the following steps may be included:
  • Step 1021 The counter is used to count the number of executions of the instruction.
  • Step 1022 When the number of executions is greater than the preset number of times, the execution of the instruction is stopped.
  • the class file corresponding to the smart contract to be invoked includes instruction 1 and instruction 2, the number of executions of instruction 1 is 1, and the number of executions of instruction 2 is 3. Assuming that instruction 2 is the instruction to be called, the instruction of instruction 2 is incremented once every time instruction 2 is executed. Thus, if the preset number of instructions 2 is set to 4, the file can be completely executed; otherwise, if the preset number of instructions 2 is set to 2, the file will not be fully executed or the prompt will be output. Wrong result.
  • different "weights” can also be assigned to different instructions.
  • the larger the value of the weight the less the preset number of instructions corresponding to the weight.
  • the weight of the corresponding instruction By adjusting the weight of the corresponding instruction, the number of executions of the instruction can be defined accordingly. For example, by increasing the weight of instruction 2, the number of times instruction 2 is allowed to execute will be further reduced; likewise, by lowering the weight of instruction 2, the number of times instruction 2 is allowed to execute will be increased.
  • the counters can be placed at different locations depending on the particular application.
  • class files including non-deterministic classes and/or non-deterministic functions can be culled when the class files are pre-deployed in a multi-node system to ensure that deterministic calculations can be performed on class files that can be executed.
  • the deployment process of the class file may include the following steps: loading the class file to be deployed by, for example, a class loader to determine whether the class file uses a non-deterministic function.
  • the deployment of the smart contract is stopped, prompting the deployment to fail. If it is determined that the class file of the smart contract does not use an undetermined function, deploy the file.
  • prompting for example, returning the result of the deployment failure to the user, thereby informing (for example, via the user-visible interface) the submitted Smart contracts cannot be deployed into the blockchain.
  • the non-determination when considering the deterministic calculation requirement of the smart contract and satisfying the finite calculation requirement, when the class file is deployed, the non-determination may not be included in the determining class file.
  • a counter corresponding to the instruction is set in the class file.
  • the class file of the smart contract can be processed by a class loader and a bytecode enhancer, wherein the class loader is used to determine whether the loaded class file contains a non-deterministic function, and rejects based on the capability.
  • the bytecode enhancer is used to parse and modify the class file, and counts each called instruction in the class file during the execution of the class file.
  • the compiled smart contract After the compiled smart contract is compiled, it will be spread in a multi-node system (for example, a blockchain) through P2P or other transmission methods, and each node will receive the class file of the smart contract.
  • the nodes in the blockchain (for example, the verification node) will agree on the received class file according to the specified rules, or save the received contract to the memory first, waiting for a new round of consensus time, triggering the share. Consensus and handling of contracts.
  • the consensus in the present invention can be directed to one or more class files.
  • the node that receives the deployment request may perform a validity check on the deployment request to determine a legitimate deployment request.
  • the legality check is a formal check on the deployment request, that is, the above node will detect the format or other parameters of the deployment request, and then determine whether the deployment request is a legitimate deployment request, for example, determining the request. Whether the format applies to the current blockchain. It can be understood that the validity test of other judgment rules also applies.
  • the above-described legality check can be performed by a consensus mechanism.
  • the format of the deployment request may be agreed upon. When all nodes consider that the format of the deployment request is legal, it is determined that the calling request is legal.
  • the PoW, the PoS, the PBFT, or other consensus algorithm is used to ensure that the node that receives the deployment request checks the validity of the deployment request to determine whether the deployment request is a legitimate deployment request for the current blockchain. Consensus-based results will result in different operations.
  • the deployment of the smart contract is ended; if the result of the consensus indicates that the deployment request is a legitimate deployment
  • the request (such as, but not limited to, the format of the deployment request conforms to the format requirements of the blockchain for the deployment request), then performs subsequent class file deployment operations.
  • a class file is pre-deployed into a class file library (for example, deployed to a local node or deployed in a storage device communicatively connected to a local node), based on The calling request finds a class file corresponding to the smart contract to be called in the class file library (step 101'), and executes the smart contract based on the found class file.
  • a class file library for example, deployed to a local node or deployed in a storage device communicatively connected to a local node
  • the calling request finds a class file corresponding to the smart contract to be called in the class file library (step 101'), and executes the smart contract based on the found class file.
  • the identification information in the call request may be acquired first (step 401), and then according to the The identification information looks up the class file corresponding to the smart contract to be called in the class file library (step 402). If the class file pointed to by the identification information is not found in the class file library, the call is stopped and the call fails (step 403). If the class file indicated by the identification information can be found in the class file library, the subsequent smart contract execution operation is performed.
  • the class file corresponding to the smart contract to be invoked may also be deployed when the call request is received.
  • the calling request of the smart contract may include some programs.
  • the logical content at this time, needs to generate a class file that satisfies the call request according to the identification information in the call request.
  • the node that receives the call request will perform a validity check on the call request.
  • the node will detect the format of the call request or other parameters to determine whether the call request is a valid call request. For example, determine if the format of the request applies to the current blockchain.
  • the validity check of the above-mentioned call request to the smart contract can also be performed by a consensus mechanism. Consensus on the format of the call request. When all nodes consider the format of the call request to be legal, it is determined that the call request is legal. For example, a PoW, PoS, PBFT, or other consensus algorithm may be used to allow a plurality of nodes that receive the call request to perform a validity check on the call request, thereby determining whether the call request is a valid call for the current blockchain. request. Based on the judgment result of the legality test, a corresponding operation will be generated. Specifically, if the call request is not a valid call request, the call to the smart contract is ended.
  • the result of the failed call is returned to the user, so that the user's visual interface is notified that the smart contract to be called is missing or cannot be called.
  • the call request is a legitimate call request (such as, but not limited to, the format of the call request conforms to the format requirement of the blockchain for the call request), then the execution of the subsequent smart contract is performed.
  • FIG. 6 is a flowchart of a method for calling a smart contract provided by an embodiment of the invention. As shown in FIG. 6, the method includes the following steps:
  • Step S601 Acquire a call request of the smart contract.
  • multiple nodes in the blockchain will receive a call request for the smart contract.
  • the call request has a particular format. It can be understood that the call request can be received by a certain node first, and then sent to multiple nodes in the blockchain by the node in a P2P manner.
  • Step S602 determining whether the calling request has legality.
  • the node that received the call request will perform a validity check on the call request.
  • the node will detect the format or other parameters of the call request, and then determine whether the call request is a valid call request. For example, determine if the format of the request applies to the current blockchain.
  • Step S602 can be performed by a consensus mechanism.
  • a consensus mechanism For example, a PoW, PoS, PBFT, or other consensus algorithm may be used to allow a plurality of nodes that receive the call request to perform a validity check on the call request, thereby determining whether the call request is a valid call for the current blockchain. request.
  • a corresponding operation will be generated. Specifically, if the call request is not a valid call request, the call of the smart contract is ended, and the operation of step S609 is performed to prompt the smart contract call to fail. For example, the result of the failed call is returned to the user, so that the user's visual interface is notified that the smart contract to be called is missing or cannot be called. If the call request is a legitimate call request (such as, but not limited to, the format of the call request conforms to the format requirement of the blockchain for the call request), the operation in step S603 is performed.
  • a legitimate call request such as, but not limited to, the format of the call request conforms to the format requirement of the blockchain for the call request
  • Step S603 Determine identification information of the smart contract corresponding to the calling request.
  • the call request has a specific format, and also includes identification information of the smart contract to be called and corresponding functions and parameters.
  • the legal call request is analyzed to determine the identification information contained in the legitimate call request for indicating the smart contract. It can be understood that in this step, the functions and parameters included in the call request can also be determined.
  • Step S604 It is judged whether there is a class file corresponding to the smart contract of the calling request.
  • a lookup is performed in the class file library (ie, the set of smart contracts that have been deployed) based on the identification information in the call request, and the corresponding operation is determined based on the result of the lookup. If the class file pointed to by the identification information is not found in the class file library, the call is stopped and the call is failed (step S609). If the class file indicated by the identification information can be found in the class file library, follow-up operations are performed.
  • the corresponding class file may also be generated according to the call request.
  • a class file that satisfies the call request will be generated by, for example, the deployment method shown in FIG. 1 or a part of the deployment method.
  • Step S605 Instantiate the smart contract.
  • step S204 the instantiation of the smart contract will be based on the class file found in step S204.
  • Step S606 Determine the function and parameters in the call request.
  • the function and parameters in the call request are determined by analyzing the call request. It can be understood that the function and the parameters in the call request can also be determined based on the result of step S603.
  • Step S607 Execute the smart contract.
  • the smart contract will be invoked in conjunction with the results of the operations of steps S605 and S606. Specifically, the smart contract corresponding to the legitimate call request is executed based on the instantiated class file and the function and parameters in the legal call request, and the result of the smart contract is output (step S608).
  • step S605 the instantiating the smart contract may be executed first (step S605), and then the function and the parameter in the invoking request are executed (step S606); or step S606 may be performed first, and then step S605 is performed.
  • FIG. 7 is a schematic structural diagram of an apparatus for processing a smart contract in a multi-node system according to an embodiment of the present invention.
  • the apparatus includes: a determining module 701 configured to determine a class file corresponding to the smart contract based on a call request for the smart contract to be invoked; and an execution module 702 configured to execute the to-be-called based on the class file Smart contract; where the class file is precompiled based on the program logic of the smart contract to be invoked.
  • the class file includes an instruction and a counter corresponding to the instruction; wherein the execution module 702 is further configured to: count the number of executions of the instruction by using a counter, and stop executing when the number of executions is greater than a preset number of times instruction.
  • the class file includes a plurality of instructions, each of which is set with a corresponding weight; wherein, the greater the value of the weight, the less the preset number of instructions corresponding to the weight.
  • the determining module 701 is further configured to: find a class file corresponding to the smart contract in the class file library based on the calling request.
  • the determining module 701 is further configured to: obtain identifier information used to indicate the smart contract in the call request; and find a class file corresponding to the smart contract in the class file library according to the identifier information.
  • the apparatus for processing a smart contract in a multi-node system further includes: a generating module 703 configured to: according to the identification information used to indicate the smart contract in the call request Generate a class file that satisfies the call request.
  • the execution module 702 is further configured to: instantiate the class file and determine functions and parameters in the call request to invoke the smart contract; and execute based on the instantiated class file and functions and parameters Call the smart contract called by the request.
  • the apparatus for processing a smart contract in a multi-node system further includes: a first verification module 704 configured to be based on a call for a smart contract to be invoked Before requesting to determine the class file corresponding to the smart contract, it is determined that the call request to invoke the smart contract is legal.
  • the first verification module 704 is further configured to: agree on the format of the call request, and determine that the call request is legal when all the nodes consider that the format of the call request is legal.
  • the apparatus for processing a smart contract in a multi-node system further includes: a deployment module 705 configured to load a class file to be deployed by using a class loader; When it is determined that the non-deterministic class and/or non-deterministic function is not included in the class file, the class file is deployed to form a class file library.
  • the deployment module 705 is further configured to: when the non-deterministic class and/or the non-deterministic function is not included in the class file, set a counter corresponding to the instruction in the class file, where the counter Used to count the number of executions of an instruction during the execution of a smart contract.
  • the deployment module 705 is further configured to deploy a class file at a local node or in a storage device communicatively coupled to the local node to form a class file library.
  • the apparatus for processing a smart contract in a multi-node system further includes: a second verification module 706 configured to determine a deployment before deploying the module deployment class file The deployment request for the class file is legal.
  • the second verification module 706 is further configured to: establish a consensus on the format of the deployment request, and determine that the call request is legal when all the nodes consider that the format of the deployment request is legal.
  • each of the modules described in the apparatus for processing a smart contract in a multi-node system provided by the above embodiment is compatible with one of the aforementioned methods for processing a smart contract in a multi-node system.
  • the method steps correspond.
  • the operations and features described in the foregoing method steps are equally applicable to the device and the corresponding modules included therein, and the repeated content is not described herein again.
  • FIG. 11 is a schematic structural diagram of an apparatus for processing a smart contract in a multi-node system according to an embodiment of the present invention.
  • the processing apparatus 300 includes an invocation request receiving unit 301, an invocation request analyzing unit 302, a class file selecting unit 303, and an executing unit 304.
  • the call request receiving unit 301 is configured to be configured to receive a call request for a smart contract and perform a validity check on the call request to determine a legitimate call request.
  • the call request analysis unit 302 is in communication connection with the call request receiving unit 301, and is configured to analyze the legal call request to obtain identification information for indicating the corresponding smart contract in the legal call request.
  • the class file selection unit 303 is configured to determine a class file of the smart contract corresponding to the legitimate call request based on the identification information. Based on the identification information, the class file selection unit 303 compares the identification information with the identification information of each class file in the class file library, thereby selecting a class file corresponding to the legal call request.
  • the execution unit 304 is configured to execute the corresponding smart contract based on the class file and the call request determined by the class file selection unit 303. Specifically, the execution unit 304 instantiates the class file and, in conjunction with the functions and parameters in the call request, implements the smart contract corresponding to the legal call request.
  • FIG. 12 is a schematic flowchart diagram of a method for deploying a smart contract in a multi-node system according to an embodiment of the present invention. As shown in FIG. 12, the method includes the following steps:
  • Step 1201 Acquire a deployment request, where the deployment request includes a class file, which is pre-compiled based on program logic of the smart contract to be deployed.
  • Step 1202 The class file is deployed in the multi-node system when it is determined that the non-deterministic class and/or the non-deterministic function is not included in the class file. For example, it is deployed at a local node or deployed in a storage device that is in communication with a local node to form a class file library.
  • any of the classes in the class file generate a call to a non-deterministic function
  • the deployment of the smart contract is stopped, prompting the deployment to fail. If it is determined that the class file of the smart contract does not use a non-deterministic function, then deploy the file.
  • prompting for example, returning the result of the deployment failure to the user, thereby informing (for example, via the user-visible interface) the submitted Smart contracts cannot be deployed into the blockchain.
  • this type of file deployment method can eliminate class files including non-deterministic classes and/or non-deterministic functions when pre-deploying class files in a multi-node system to ensure that class files can be executed.
  • Deterministic calculations can be implemented to meet the following requirements when combining blockchain techniques to implement smart contracts: on different nodes, the same input can get the same output at different times.
  • the method for deploying the smart contract in the multi-node system may be The method further includes: when determining that the non-deterministic class and/or the non-deterministic function is not included in the class file, setting a counter corresponding to the instruction in the class file, wherein the counter is used for the instruction in the process of executing the smart contract The number of executions is counted (step 1301).
  • the class file of the smart contract can be processed by a class loader and a bytecode enhancer, wherein the class loader is used to determine whether the loaded class file contains a non-deterministic function, and rejects based on the capability.
  • the bytecode enhancer is used to parse and modify the class file, and counts each called instruction in the class file during the execution of the class file.
  • the compiled smart contract After the compiled smart contract is compiled, it will be spread in a multi-node system (for example, a blockchain) through P2P or other transmission methods, and each node will receive the class file of the smart contract.
  • the nodes in the blockchain (for example, the verification node) will agree on the received class file according to the specified rules, or save the received contract to the memory first, waiting for a new round of consensus time, triggering the share. Consensus and handling of contracts.
  • the consensus in the present invention can be directed to one or more class files.
  • the node that receives the deployment request may perform a validity check on the deployment request to determine a legitimate deployment request.
  • the legality check is a formal check on the deployment request, that is, the above node will detect the format or other parameters of the deployment request, and then determine whether the deployment request is a legitimate deployment request, for example, determining the request. Whether the format applies to the current blockchain. It can be understood that the validity test of other judgment rules also applies.
  • the above-described legality check can be performed by a consensus mechanism.
  • the format of the deployment request may be agreed upon. When all nodes consider that the format of the deployment request is legal, it is determined that the calling request is legal.
  • the PoW, the PoS, the PBFT, or other consensus algorithm is used to ensure that the node that receives the deployment request checks the validity of the deployment request to determine whether the deployment request is a legitimate deployment request for the current blockchain. Consensus-based results will result in different operations.
  • the deployment of the smart contract is ended; if the result of the consensus indicates that the deployment request is a legitimate deployment
  • the request (such as, but not limited to, the format of the deployment request conforms to the format requirements of the blockchain for the deployment request), then performs subsequent class file deployment operations.
  • FIG. 15a is a flowchart of a method for deploying a smart contract according to an embodiment of the present invention. As shown in FIG. 15, the deployment method of the smart contract includes the following steps:
  • Step S1501 Acquire a deployment request of the smart contract.
  • the deployment request has a specific format and includes the class file of the smart contract (ie, the class file to be deployed). It can be understood that the deployment request can be received by a certain node first, and then sent by the node to multiple nodes in the blockchain in a P2P manner.
  • step S1502 it is determined whether the deployment request has legality.
  • the node that receives the deployment request will perform a validity check on the deployment request to determine a legitimate deployment request.
  • the validity check is a formal check on the deployment request, that is, the node detects the format or other parameters of the deployment request, and then determines whether the deployment request is a legitimate deployment request. For example, determine if the format of the request applies to the current blockchain. It can be understood that the validity test of other judgment rules also applies.
  • step S1502 can be performed by a consensus mechanism. Specifically, the PoW, the PoS, the PBFT, or other consensus algorithm is used to enable the node that receives the deployment request to check the validity of the deployment request, and determine whether the deployment request is legal for the current blockchain. request.
  • the PoW the PoW
  • the PoS the PoS
  • the PBFT or other consensus algorithm is used to enable the node that receives the deployment request to check the validity of the deployment request, and determine whether the deployment request is legal for the current blockchain. request.
  • step S1503 Based on the result of the consensus in step S1502, different operations will be generated. Specifically, if the result of the consensus indicates that the deployment request is not a legitimate deployment request (for example, the format of the deployment request does not meet the requirements), the deployment of the smart contract is ended; if the result of the consensus indicates that the deployment request is a legitimate deployment The request (such as, but not limited to, the format of the deployment request conforms to the format requirement of the blockchain for the deployment request), then the operation in step S1503 is performed.
  • Step S1503 Determine whether the deployment request has non-determinism.
  • the deployment request has a specific format and includes a class file to be deployed. Therefore, for example, the class loader can be used to determine whether the class file to be deployed uses a non-deterministic function. If any class in the class file generates a call to the non-deterministic function, the deployment of the smart contract is stopped. , in turn, prompting the deployment to fail (step S1507). If the class loader discriminates that the class file of the smart contract does not use a non-deterministic function (ie, the non-deterministic class is not included in the class file), the operation in step S1504 is performed.
  • the class loader discriminates that the class file of the smart contract does not use a non-deterministic function (ie, the non-deterministic class is not included in the class file).
  • the operation in step S1504 is performed.
  • Step S1504 Add a counter.
  • the counter will be set after the specified instruction, so that the counting of the called instruction can be realized.
  • the execution of the class file after the counter is added will be described below with reference to FIG. 15b.
  • the class file 400 will execute the instruction 1 number 1 and the execution instruction 2 number 3 during execution. As described above, assuming that instruction 2 is the specified instruction, the counter is incremented once each time instruction 2 is executed. Thus, if the threshold for the number of executions of the instruction 2 is set to be greater than or equal to 4, the class file 400 can be completely executed; conversely, if the threshold for the number of executions of the instruction 2 is set to 2, the class file 400 cannot be completely executed. Or output a result that prompts an error.
  • different "weights" can also be assigned to different instructions. Still taking the instruction shown in FIG. 14b as an example, by adjusting the weight of the corresponding instruction, the number of executions of the instruction can be specified accordingly. For example, by increasing the weight of instruction 2, the number of times instruction 2 is allowed to execute will be further reduced; likewise, by lowering the weight of instruction 2, the number of times instruction 2 is allowed to execute will be increased.
  • the counters can be placed at different locations depending on the particular application.
  • Step 1505 Store the modified class file.
  • the unmodified class file to be deployed does not contain a counter.
  • the class file is modified by a bytecode enhancement technique to add a counter after the specified instruction.
  • the modified class file to be deployed will be stored in a specified location (for example, stored at a node of the blockchain or stored in a storage device connected to the node), thereby implementing the class file to be deployed to the class.
  • the file library complete the construction of the class file library.
  • step S1506 the deployment is successful.
  • the successful result of the deployment is returned to the user, so that the user's visual interface is informed that the submitted smart contract has been deployed to the blockchain.
  • the deployment of the class files of the smart contract is realized, and the class files in the blockchain are both deterministic and limited, thereby improving the stability of the network.
  • the class file to be deployed is filtered based on whether the class file includes a non-deterministic class and/or a non-deterministic function or a non-deterministic class, so that the filtered and retained class files are all deterministic.
  • the instruction since the counter is set after the specified instruction of the modified class file, when a threshold is set for the number of calls of the instruction, the instruction can be limited by comparing the output value of the counter with the threshold of the number of calls. The number of calls, which in turn makes the class file have limited computational features when called.
  • FIG. 16 is a schematic structural diagram of an apparatus for deploying a smart contract in a multi-node system according to an embodiment of the present invention. As shown in Figure 16, the device includes:
  • the obtaining module 1601 is configured to obtain a deployment request, where the deployment request includes a class file, which is pre-compiled based on program logic of the smart contract to be deployed;
  • the deployment execution module 1602 is configured to deploy the class files in the multi-node system when it is determined that the non-deterministic class and/or the non-deterministic function is not included in the class file.
  • the deployment execution module 1602 is further configured to: when the non-deterministic class and/or the non-deterministic function is not included in the class file, set a counter corresponding to the instruction in the class file, where The counter is used to count the number of executions of the instruction during the execution of the smart contract.
  • the deployment execution module 1602 is further configured to deploy a class file at a local node or in a storage device communicatively coupled to the local node to form a class file library.
  • the apparatus for deploying a smart contract in a multi-node system further includes: a third verification module 1603 configured to determine deployment of the deployment class file before deploying the class file The request is legal.
  • the third verification module 1603 is further configured to: implement a consensus on the format of the deployment request, and determine that the call request is legal when all the nodes consider that the format of the deployment request is legal.
  • each of the modules described in the apparatus for deploying smart contracts in a multi-node system is compatible with one of the aforementioned methods for deploying smart contracts in a multi-node system.
  • the method steps correspond.
  • the operations and features described in the foregoing method steps are equally applicable to the device and the corresponding modules included therein, and the repeated content is not described herein again.
  • any of the preceding methods may also be implemented as machine readable instructions comprising a program executed by a processor.
  • the program can be embodied in software stored on a tangible computer readable medium such as a CD-ROM, floppy disk, hard disk, digital versatile disk (DVD), Blu-ray disk or other form of memory.
  • some or all of the steps of any of the prior methods may utilize any of an application specific integrated circuit (ASIC), a programmable logic device (PLD), a field programmable logic device (EPLD), discrete logic, hardware, firmware, and the like.
  • ASIC application specific integrated circuit
  • PLD programmable logic device
  • EPLD field programmable logic device
  • the encoding of instructions can be utilized to implement a process of any of the preceding methods, which is stored on a tangible computer readable medium, such as a hard disk, a flash memory, a read only memory (ROM), a compact disk. (CD), digital versatile disc (DVD), cache, random access memory (RAM), and/or any other storage medium on which information can be stored for any time (eg, long, permanent, transient) Situation, temporary buffering, and/or caching of information).
  • a tangible computer readable medium such as a hard disk, a flash memory, a read only memory (ROM), a compact disk. (CD), digital versatile disc (DVD), cache, random access memory (RAM), and/or any other storage medium on which information can be stored for any time (eg, long, permanent, transient) Situation, temporary buffering, and/or caching of information).
  • a tangible computer readable medium such as a hard disk, a flash memory, a read only memory (ROM), a compact disk. (CD), digital versatile disc (DVD
  • an example process such as the previous method may be implemented with encoded instructions (such as computer readable instructions) stored on a non-transitory computer readable medium, such as a hard disk, flash memory, read only memory, optical disk , a digital versatile disc, a cache, a random access memory, and/or any other storage medium in which information can be stored at any time (eg, for a long time, permanently, transiently, temporarily buffered, and/or informational) Cache).
  • a non-transitory computer readable medium such as a hard disk, flash memory, read only memory, optical disk , a digital versatile disc, a cache, a random access memory, and/or any other storage medium in which information can be stored at any time (eg, for a long time, permanently, transiently, temporarily buffered, and/or informational) Cache).
  • the invention supports the development of intelligent contracts in the Java language, and has the characteristics of deterministic calculation and limited calculation. It does not need to additionally develop a compiler and an interpreter, and basically retains all the functions of the Java language, and is easy to access and use.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • General Business, Economics & Management (AREA)
  • General Engineering & Computer Science (AREA)
  • Development Economics (AREA)
  • Finance (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Human Resources & Organizations (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Data Mining & Analysis (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Stored Programmes (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

一种智能合约处理方法及装置，该处理方法包括：基于与待调用的智能合约所对应的类文件执行所述待调用的智能合约（102）；其中，所述类文件基于所述待调用的智能合约的程序逻辑预先编译而成。通过采用该处理方法，支持Java语言开发智能合约，不需要额外开发编译器、解释器，基本保留了Java语言的所有功能，易于接入使用。

Description

智能合约处理方法及装置
本申请要求2017年07月31日提交的申请号为No.201710638423.X的中国申请的优先权，通过引用将其全部内容并入本文。
技术领域
本发明属于计算机数据处理领域，尤其涉及一种智能合约处理方法及装置。
发明背景
智能合约是一套以数字形式定义的承诺，合约参与方可以在上面执行这些承诺的协议。智能合约的本身与合约执行过程能够被观察，并且合约执行的过程与判决都能够被验证。智能合约的本身及与合约相关的信息只有相关的合约方才能够接触，当发生冲突的时候才会把相关信息暴露给第三方审查。
区块链技术是基于去中心化的对等网络，将密码学原理与共识机制相结合，来保障分布式各节点的数据连贯和持续，实现信息即时验证、可追溯、难篡改和无法屏蔽，从而创造了一套隐私、高效、安全的共享价值体系。智能合约是指由区块链技术提供的实现复杂功能的去中心化应用技术。智能合约由高级语言编写，经对应的编译器编译之后生成区块链能够识别并执行的编码，部署在区块链之中，提供对应的功能。
用于执行智能合约的系统或者模块，一般称为智能合约的执行引擎。现有的智能合约执行引擎主要通过创建一种脚本语言及其解释器来实现，存在以下问题：(1)学习成本高，开发人员为了使用这类区块链，还需要学习这个对应的脚本语言；(2)不具备普适性，一般来说，一种脚本语言只能在特定的区块链平台上使用；(3)功能有限，这类脚本语言仅能支持简单的运算，难以满足商用、工程级别的需求。
因此，亟需一种能够克服上述缺陷的智能合约处理方法以及对应的装置。
发明内容
本发明针对上述问题，提出一种智能合约处理方法及装置。
根据本发明的一个方面，提供一种用于在多节点系统中对智能合约进行处理的方法，包括：基于针对待调用的智能合约的调用请求确定所述智能合约所对应的类文件；以及基于所述类文件执行所述智能合约；其中，所述类文件基于所述智能合约的程序逻辑预先编译而成。
在本发明一实施例中，所述类文件包括指令和与所述指令相对应的计数器；其中，所述基于所述类文件执行所述智能合约包括：利用所述计数器对所述指令的执行次数进行计数，当所述执行次数大于预设次数时，停止执行所述指令。
在本发明一实施例中，所述类文件包括多个所述指令，每个所述指令设置有对应的权重；其中，所述权重的值越大，与所述权重对应的所述指令的所述预设次数越少。
在本发明一实施例中，所述基于针对待调用的智能合约的调用请求确定所述智能合约所对应的类文件包括：基于所述调用请求在类文件库中查找与所述智能合约所对应的类文件。
在本发明一实施例中，所述基于所述调用请求在类文件库中查找与待调用的所述智能合约所对应的类文件包括：获取所述调用请求中用于指示所述智能合约的标识信息；以及根据所述标识信息在所述类文件库中查找与所述智能合约所对应的类文件。
在本发明一实施例中，所述基于针对待调用的智能合约的调用请求确定所述待调用的智能合约所对应的类文件包括：根据所述调用请求中用于指示所述智能合约的标识信息生成满足所述调用请求的所述类文件。
在本发明一实施例中，所述基于所述类文件执行所述智能合约包括：对所述类文件进行实例化，并且确定所述调用请求中的函数和参数；以及基于经实例化的所述类文件以及所述函数和参数来执行所述智能合约。
在本发明一实施例中，在基于针对待调用的智能合约的调用请求确定所述智能合约所对应的类文件之前，所述用于在多节点系统中对智能合约进行处理的方法进一步包括：确定所述调用请求合法。
在本发明一实施例中，所述确定所述调用请求合法包括：对所述调用请求的格式进行共识，当所有节点都认为所述调用请求的格式为合法时，确定所述调用请求合法。
在本发明一实施例中，所述类文件预先部署在所述多节点系统中，其中，所述类文件的部署过程包括：通过类加载器加载待部署的所述类文件；以及当确定所述类文件中并未包括非确定性类和/或非确定性函数时，部署所述类文件以形成类文件库。
在本发明一实施例中，所述类文件的部署过程进一步包括：当确定所述类文件中并未包括非确定性类和/或非确定性函数时，在所述类文件中设置与指令对应的计数器，其中，所述计数器用于在所述智能合约执行的过程中对所述指令的执行次数计数。
在本发明一实施例中，在部署所述类文件之前，所述用于在多节点系统中对智能合约进行处理的方法进一步包括：确定部署所述类文件的部署请求合法。
在本发明一实施例中，所述确定部署所述类文件的部署请求合法包括：对所述部署请求的格式进行共识，当所有节点都认为所述部署请求的格式为合法时，确定所述调用请求合法。
根据本发明的另一个方面，还提供一种用于在多节点系统中对智能合约进行处理的装置，包括：确定模块，配置为基于针对待调用的智能合约的调用请求确定所述智能合约所对应的类文件；以及执行模块，配置为基于与待调用的智能合约所对应的类文件执行所述待调用的智能合约；其中，所述类文件基于所述待调用的智能合约的程序逻辑预先编译而成。
在本发明一实施例中，所述类文件包括指令和与所述指令相对应的计数器；其中，所述执行模块进一步配置为：利用所述计数器对所述指令的执行次数进行计数，当所述执行次数大于预设次数时，停止执行所述指令。
在本发明一实施例中，所述类文件包括多个所述指令，每个所述指令设置有对应的权重；其中，所述权重的值越大，与所述权重对应的所述指令的所述预设次数越少。
在本发明一实施例中，所述确定模块进一步配置为：基于所述调用请求在类文件库中查找与所述智能合约所对应的类文件。
在本发明一实施例中，所述确定模块进一步配置为：获取所述调用请求中用于指示所述智能合约的标识信息；以及根据所述标识信息在所述类文件库中查找与所述智能合约所对应的类文件。
在本发明一实施例中，所述用于在多节点系统中对智能合约进行处理的装置进一步包括：生成模块，配置为根据所述调用请求中用于指示所述智能合约的标识信息生成满足所述调用请求的所述类文件。
在本发明一实施例中，所述执行模块进一步配置为：对所述类文件进行实例化，并且确定调用所述智能合约的调用请求中的函数和参数；以及基于经实例化的所述类文件以及所述函数和参数来执行所述调用请求所调用的所述智能合约。
在本发明一实施例中，所述用于在多节点系统中对智能合约进行处理的装置进一步包括：第一验证模块，配置为在基于针对待调用的智能合约的调用请求确定所述智能合约所对应的类文件之前，确定调用所述智能合约的调用请求合法。
在本发明一实施例中，所述第一验证模块进一步配置为：对所述调用请求的格式进行共识，当所有节点都认为所述调用请求的格式为合法时，确定所述调用请求合法。
在本发明一实施例中，所述用于在多节点系统中对智能合约进行处理的装置进一步包括：部署模块，配置为通过类加载器加载待部署的所述类文件；以及当确定所述类文件中并未包括非确定性类和/或非确定性函数时，部署所述类文件以形成类文件库。
在本发明一实施例中，所述部署模块进一步配置为：当确定所述类文件中并未包括非确定性类和/或非确定性函数时，在所述类文件中设置与指令对应的计数器，其中，所述计数器用于在所述智能合约执行的过程中对所述指令的执行次数计数。
在本发明一实施例中，所述部署模块进一步配置为：在本地节点处或在与所述本地节点通 信连接的存储设备中部署所述类文件，以形成类文件库。
在本发明一实施例中，所述用于在多节点系统中对智能合约进行处理的装置进一步包括：第二验证模块，配置为在所述部署模块部署所述类文件之前，确定部署所述类文件的部署请求合法。
在本发明一实施例中，所述第二验证模块进一步配置为：对所述部署请求的格式进行共识，当所有节点都认为所述部署请求的格式为合法时，确定所述调用请求合法。
根据本发明的另一个方面，还提供一种在多节点系统中对智能合约进行部署的方法，包括：获取包括智能合约类文件的部署请求，其中，所述部署请求包括类文件，所述类文件基于待部署的智能合约的程序逻辑预先编译而成；以及当确定所述类文件中并未包括非确定性类和/或非确定性函数时，将所述类文件部署在所述多节点系统中。
在本发明一实施例中，所述类文件的部署过程进一步包括：当确定所述类文件中并未包括非确定性类和/或非确定性函数时，在所述类文件中设置与指令对应的计数器，其中，所述计数器用于在所述智能合约执行的过程中对所述指令的执行次数计数。
在本发明一实施例中，所述类文件部署在本地节点处或部署在与所述本地节点通信连接的存储设备中，以形成类文件库。
在本发明一实施例中，在部署所述类文件之前，所述在多节点系统中对智能合约进行部署的方法进一步包括：确定部署所述类文件的部署请求合法。
在本发明一实施例中，所述确定部署所述类文件的部署请求合法包括：对所述部署请求的格式进行共识，当所有节点都认为所述部署请求的格式为合法时，确定所述调用请求合法。
根据本发明的另一个方面，还提供一种在多节点系统中对智能合约进行部署的装置，包括：获取模块，配置为获取部署请求，其中，所述部署请求包括类文件，所述类文件基于待部署的智能合约的程序逻辑预先编译而成；以及部署执行模块，配置为当确定所述类文件中并未包括非确定性类和/或非确定性函数时，将所述类文件部署在所述多节点系统中。
在本发明一实施例中，所述部署执行模块进一步配置为：当确定所述类文件中并未包括非确定性类和/或非确定性函数时，在所述类文件中设置与指令对应的计数器，其中，所述计数器用于在所述智能合约执行的过程中对所述指令的执行次数计数。
在本发明一实施例中，所述部署执行模块进一步配置为：在本地节点处或在与所述本地节点通信连接的存储设备中部署所述类文件，以形成类文件库。
在本发明一实施例中，第三验证模块，配置为在部署所述类文件之前，确定部署所述类文件的部署请求合法。
在本发明一实施例中，所述第三验证模块进一步配置为：对所述部署请求的格式进行共识，当所有节点都认为所述部署请求的格式为合法时，确定所述调用请求合法。
根据本发明的另一个方面，还提供一种计算机设备，包括存储器、处理器以及存储在所述存储器上被所述处理器执行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如前任一所述的用于在多节点系统中对智能合约进行处理的方法的步骤，或任一所述的在多节点系统中对智能合约进行部署的方法的步骤。
根据本发明的另一个方面，还提供一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如前任一所述的用于在多节点系统中对智能合约进行处理的方法的步骤，或任一所述的在多节点系统中对智能合约进行部署的方法的步骤。
通过实施本发明的技术方案，可以基于Java语言开发智能合约，同时具有确定性计算、有限计算的特点，不需要额外开发编译器、解释器，基本保留了Java语言的所有功能，易于接入使用，适合推广。
附图简要说明
参考附图示出并阐明实施例。这些附图用于阐明基本原理，从而仅仅示出了对于理解基本原理必要的方面。这些附图不是按比例的。在附图中，相同的附图标记表示相似的特征。
图1所示为本发明一实施例提供的一种用于在多节点系统中对智能合约进行处理的方法的 流程示意图。
图2所示为本发明一实施例提供的一种用于在多节点系统中对智能合约进行处理的方法中执行待调用的智能合约的流程示意图。
图3所示为本发明另一实施例提供的一种用于在多节点系统中对智能合约进行处理的方法的流程示意图。
图4所示为本发明另一实施例提供的一种用于在多节点系统中对智能合约进行处理的方法的流程示意图。
图5所示为本发明另一实施例提供的一种用于在多节点系统中对智能合约进行处理的方法的流程示意图。
图6所示为发明一实施例所提供的智能合约的调用方法的流程图。
图7所示为本发明一实施例提供一种用于在多节点系统中对智能合约进行处理的装置的结构示意图。
图8所示为本发明另一实施例提供一种用于在多节点系统中对智能合约进行处理的装置的结构示意图。
图9所示为本发明另一实施例提供一种用于在多节点系统中对智能合约进行处理的装置的结构示意图。
图10所示为本发明另一实施例提供一种用于在多节点系统中对智能合约进行处理的装置的结构示意图。
图11为本发明一实施例提供的用于在多节点系统中对智能合约进行处理的装置的架构示意图。
图12为本发明一实施例提供的一种在多节点系统中对智能合约进行部署的方法的流程示意图。
图13为本发明另一实施例提供的一种在多节点系统中对智能合约进行部署的方法的流程示意图。
图14为本发明另一实施例提供的一种在多节点系统中对智能合约进行部署的方法的流程示意图。
图15a为本发明一实施例提供的智能合约的部署方法的流程图。
图15b为本发明一实施例提供的类文件的结构示意图。
图16所示为本发明一实施例提供的一种在多节点系统中对智能合约进行部署的装置的结构示意图。
图17所示为本发明另一实施例提供的一种在多节点系统中对智能合约进行部署的装置的结构示意图。
实施本发明的方式
在以下优选的实施例的具体描述中，将参考构成本发明一部分的所附的附图。所附的附图通过示例的方式示出了能够实现本发明的特定的实施例。示例的实施例并不旨在穷尽根据本发明的所有实施例。可以理解，在不偏离本发明的范围的前提下，可以利用其他实施例，也可以进行结构性或者逻辑性的修改。因此，以下的具体描述并非限制性的，且本发明的范围由所附的权利要求所限定。
对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论，但在适当情况下，所述技术、方法和设备应当被视为说明书的一部分。对于附图中的各单元之间的连线，仅仅是为了便于说明，其表示至少连线两端的单元是相互通信的，并非旨在限制未连线的单元之间无法通信。
首先，对本发明所涉及的名词和相关技术进行阐述。Java语言是一种高级程序设计语言，类文件(Class file)是Java源代码经过编译后的产物，承载了具体的程序逻辑。运行Java程序的环境叫做Java虚拟机(JVM)。Java虚拟机提供了类加载(Class Loading)机制，通过该机制，可以对Java运行时的类文件进行管理，实现该机制的功能模块称为类加载器(Class Loader)。 确定性函数是指每次使用特定的输入值集来被调用时，确定性函数总是返回相同的值；对应地，如果返回不同的结果，则该函数为非确定性函数。
图1所示为本发明一实施例提供的一种用于在多节点系统中对智能合约进行处理的方法的流程示意图。如图1所示，该方法包括如下步骤：
步骤101：基于针对待调用的智能合约的调用请求确定所述智能合约所对应的类文件(Class file)。该类文件基于待调用的智能合约的程序逻辑预先编译而成。
步骤102：基于该类文件执行待调用的智能合约。具体的执行过程可包括：先对类文件进行实例化，并且确定调用智能合约的调用请求中的函数和参数；然后基于经实例化的类文件以及函数和参数来执行调用请求所调用的智能合约。
由此可见，本发明实施例其实提供了一种基于Java虚拟机的智能合约执行系统(执行引擎)以及与该系统相对应的流程和算法。采用该执行系统的区块链平台，能够支持使用Java语言开发智能合约。更进一步地，能够支持运行在Java虚拟机上的所有语言(也称为JVM语言)，包括Scala，Groovy，Jython等。由于智能合约的程序逻辑被编译成了基于Java语言实现的类文件，因此就实现基于Java语言开发智能合约，不再需要额外开发编译器、解释器。开发人员采用Java语言功能即可实现区块链技术的开发和使用，易于接入以满足工程级别应用、易于商业使用，且适合市场推广。
应当理解，由于类文件为根据智能合约编译而成，因此类文件的内容其实包括了智能合约的程序逻辑内容，因此在后面有些实施例的描述中，并未对类文件的概念和智能合约的概念做严格逻辑区分。例如，当要实现对智能合约的调用、执行以及部署时，实际上是在执行对类文件的调用、执行以及部署。
在本发明一实施例中，由于发明人通过研究发现，当结合区块链技术来实现智能合约时，智能合约需要满足如下要求：计算是有限的，不应该出现死循环和无限递归。因此，类文件可包括指令和与指令相对应的计数器。此时如图2所示，在执行待调用的智能合约时，可包括如下步骤：
步骤1021：利用该计数器对指令的执行次数进行计数。
步骤1022：当执行次数大于预设次数时，则停止执行指令。
例如，假设待调用的智能合约所对应的类文件包括指令1和指令2，指令1的执行次数为1，指令2的执行次数为3。假设指令2为待调用的指令，则指令2每执行一次，指令2的计数器便增加计数一次。如此，如果将对指令2的预设次数设置为4，则该类文件能够完全执行；反之，如果将对指令2的预设次数设置为2，则该类文件将无法完全执行或是输出提示错误的结果。
在一种实施方式中，还可以为不同指令赋予不同的“权重”。权重的值越大，与权重对应的指令的预设次数越少。通过调整相应的指令的权重，可以对指令的执行次数进行相应地限定。譬如，通过提升指令2的权重，指令2被允许执行的次数将进一步地减少；同样，通过降低指令2的权重，指令2被允许执行的次数将得到提升。
因此，通过对指令的计数来防止某一用户/节点故意或因故障而产生对某一指令的大量重复的调用，保证了区块链的有限计算的特点。例如，在竞标系统中，通过在对应于撤回竞标操作的指令的后面增添计数器，可以防止用户恶意地反复撤回竞标，避免整个竞标系统的因某一个用户的操作而导致瘫痪或无法正常工作。可以理解的，计数器可以根据具体的应用而设置于不同的位置。
在本发明一实施例中，由于发明人通过研究发现，当结合区块链技术来实现智能合约时，智能合约还需要满足如下要求：在不同的节点上，在不同的时间，相同的输入可以得到相同的输出，或称为确定性计算。因此，可在将类文件预先部署在多节点系统中时，剔除包括非确定性类和/或非确定性函数的类文件，以保证可被执行的类文件都可实现确定性计算。具体而言，类文件的部署过程可包括如下步骤：通过例如类加载器来加载待部署的类文件，以判断该类文件是否使用了非确定性的函数。如果该类文件中存在任意一个类产生了对非确定性函数的调用，则停止部署该智能合约，进而提示部署失败。如果判别出该智能合约的类文件并未使用非 确定性的函数，则部署该类文件。本领域的技术人员能够理解的是，在不同的应用中，可以存在不同方式的提示，譬如，将部署失败的结果返回给用户，从而告知(譬如，经由用户可视的界面)其所提交的智能合约无法部署到区块链中。
在本发明一实施例中，当考虑到既要满足智能合约的确定性计算要求，又要满足有限计算要求时，在对类文件进行部署时，可在当确定类文件中并未包括非确定性类和/或非确定性函数时，再在类文件中设置与指令对应的计数器。具体而言，可通过基于类加载器和字节码增强器来对智能合约的类文件进行处理，其中，类加载器用于判别加载的类文件是否含有非确定性的函数，并基于此能力拒绝加载含有非确定性函数的类；字节码增强器用于分析和修改类文件，在类文件被执行的过程中，对类文件中各个被调用的指令进行计数。编写好的智能合约经过编译后，将通过P2P或其它传输方式在多节点系统(譬如，区块链)中扩散，每个节点都会收到该智能合约的类文件。区块链中的节点(譬如，验证节点)会依据指定的规则对收到的类文件进行共识，或者将收到的合约先保存到内存中，等待新一轮的共识时间，触发对该份合约的共识和处理。可以理解的，本发明中的共识可以针对一个或多个类文件。
在本发明一实施例中，为了提高类文件部署操作的可靠性，在部署类文件之前，需要先确定部署该类文件的部署请求合法。具体而言，接收到该部署请求的节点可对该部署请求进行合法性检验，以确定合法的部署请求。合法性检验是对该部署请求进行形式上的检验，也就是说，上述节点将对该部署请求的格式或其它参数进行检测，进而判断该部署请求是否是合法的部署请求，例如，判断该请求的格式是否适用于当前的区块链。可以理解的是，其它判断规则的合法性检验也适用。
在一进一步实施例中，对于区块链，上述合法性检验可以通过共识的机制来执行。具体而言，可对部署请求的格式进行共识，当所有节点都认为部署请求的格式为合法时，确定调用请求合法。通过PoW、PoS、PBFT或者其它共识算法，让多个接收到该部署请求的节点对该部署请求进行合法性检验，进而确定该部署请求对于当前的区块链是否为合法的部署请求。基于共识的结果，将产生不同的操作。具体而言，如果共识的结果指示该部署请求不是合法的部署请求(譬如，该部署请求的格式不符合要求)，则结束该智能合约的部署；如果共识的结果指示该部署请求是合法的部署请求(譬如但不限于，该部署请求的格式符合该区块链对部署请求的格式要求)，则执行后续的类文件部署操作。
在本发明一实施例中，如图3所示，当类文件被预先部署到一个类文件库中时(例如部署到本地节点处或部署在与本地节点通信连接的存储设备中)，要基于调用请求在类文件库中查找与待调用的智能合约所对应的类文件(步骤101’)，再基于该查找到的类文件执行该智能合约。
在一进一步实施例中，如图4所示，当调用智能合约的调用请求中包括了用于指示智能合约的标识信息时，可先获取调用请求中的标识信息(步骤401)，再根据该标识信息在类文件库中查找与待调用的智能合约所对应的类文件(步骤402)。如未在类文件库中查找到该标识信息所指向的类文件，则停止调用并提示调用失败(步骤403)。如果能够在类文件库中查找到标识信息所指示的类文件，则进行后续智能合约的执行操作。
在本发明另一实施例中，与待调用的智能合约所对应的类文件也可以是在接收到调用请求时才进行部署的，具体而言，调用智能合约的调用请求中可能包括了一些程序逻辑内容，此时则需要根据调用请求中的标识信息来生成满足该调用请求的类文件。
在本发明一实施例中，如图5所示，为了提高调用智能合约操作的可靠性，可在基于类文件执行智能合约之前，先确定调用该智能合约的调用请求合法(步骤501)。具体而言，接收到该调用请求的节点将对该调用请求进行合法性检验。节点将对该调用请求的格式或其它参数进行检测，进而判断该调用请求是否是合法的调用请求。例如，判断该请求的格式是否适用于当前的区块链。
在一进一步实施例中，上述对智能合约的调用请求的合法性检验也可以通过共识的机制来执行。对调用请求的格式进行共识，当所有节点都认为调用请求的格式为合法时，确定调用请求合法。譬如，可以通过PoW、PoS、PBFT或者其它共识算法，让多个接收到该调用请求的 节点对该调用请求进行合法性检验，进而确定该到调用请求对于当前的区块链是否为合法的调用请求。基于合法性检验的判断结果，将产生对应的操作。具体而言，如果该调用请求不是合法的调用请求，则结束该智能合约的调用。譬如，将调用失败的结果返回给用户，从而在用户可视的界面上告知其欲调用的智能合约缺失或无法调用。如果该调用请求是合法的调用请求(譬如但不限于，该调用请求的格式符合该区块链对调用请求的格式要求)，则执行后续智能合约的执行操作。
图6所示为发明一实施例所提供的智能合约的调用方法的流程图。如图6所示，该方法包括如下步骤：
步骤S601：获取智能合约的调用请求。
在该步骤中，区块链中的多个节点将接收到智能合约的调用请求。在此实施例中，该调用请求具有特定格式。可以理解的，调用请求可以先由某个节点接收到，然后通过该节点以P2P的方式发送到区块链中的多个节点。
步骤S602，判断调用请求是否具备合法性。
在该步骤中，接收到该调用请求的节点将对该调用请求进行合法性检验。在此实施例中，上述节点将对该调用请求的格式或其它参数进行检测，进而判断该调用请求是否是合法的调用请求。例如，判断该请求的格式是否适用于当前的区块链。
步骤S602可以通过共识的机制来执行。譬如，可以通过PoW、PoS、PBFT或者其它共识算法，让多个接收到该调用请求的节点对该调用请求进行合法性检验，进而确定该到调用请求对于当前的区块链是否为合法的调用请求。
基于步骤S602中的判断结果，将产生对应的操作。具体而言，如果该调用请求不是合法的调用请求，则结束该智能合约的调用，执行步骤S609的操作，以提示智能合约调用失败。譬如，将调用失败的结果返回给用户，从而在用户可视的界面上告知其欲调用的智能合约缺失或无法调用。如果该调用请求是合法的调用请求(譬如但不限于，该调用请求的格式符合该区块链对调用请求的格式要求)，则执行步骤S603中的操作。
步骤S603：确定对应于调用请求的智能合约的标识信息。
在本实施例中，调用请求具备特定的格式，并且还包括所要调用的智能合约的标识信息以及对应的函数和参数。在此步骤中，将对合法的调用请求进行分析，确定包含在该合法的调用请求中的、用于指示智能合约的标识信息。可以理解的，在此步骤中，还可以确定调用请求中所包含的函数和参数。
步骤S604：判断是否存在对应于调用请求的智能合约的类文件。
在该步骤中，将基于调用请求中的标识信息，在类文件库(即，已经部署的智能合约的集合)中进行查找，并且根据该查找的结果来确定对应的操作。如未在类文件库中查找到该标识信息所指向的类文件，则停止调用并提示调用失败(步骤S609)。如果能够在类文件库中查找到标识信息所指示的类文件，则进行后续操作。
可以理解的，在一种实施方式中，也可以根据该调用请求来生成相应的类文件。譬如，在获取该调用请求中所包含的标识信息后，将通过例如图1中所示的部署方法或该部署方法的一部分来生成满足调用请求的类文件。
步骤S605：实例化智能合约。
在该步骤中，将基于步骤S204中所查找到的类文件，来进行智能合约的实例化。
步骤S606：确定调用请求中的函数以及参数。
在该步骤中，通过对调用请求进行分析来确定调用请求中的函数以及参数。可以理解的，还可以使用基于步骤S603的结果来确定调用请求中的函数以及参数。
步骤S607：执行智能合约。
在该步骤中，将结合步骤S605和S606的操作结果，来调用智能合约。具体而言，基于经实例化的类文件以及合法的调用请求中的函数和参数来执行与该合法的调用请求相对应的智能合约，进而输出智能合约的结果(步骤S608)。
可以理解的，虽然上述步骤采用了顺序的编号，但本领域技术人员能够理解的是，上述步 骤中的一些步骤的顺序也可以进行变动。譬如，可以先执行实例化智能合约(步骤S605)，后执行确定调用请求中的函数以及参数(步骤S606)；也可以先执行步骤S606，后执行步骤S605。
图7所示为本发明一实施例提供一种用于在多节点系统中对智能合约进行处理的装置的结构示意图。如图7所示，该装置包括：确定模块701，配置为基于针对待调用的智能合约的调用请求确定智能合约所对应的类文件；以及执行模块702，配置为基于该类文件执行待调用的智能合约；其中，类文件基于待调用的智能合约的程序逻辑预先编译而成。
在本发明一实施例中，类文件包括指令和与指令相对应的计数器；其中，执行模块702进一步配置为：利用计数器对指令的执行次数进行计数，当执行次数大于预设次数时，停止执行指令。
在本发明一实施例中，类文件包括多个指令，每个指令设置有对应的权重；中，权重的值越大，与权重对应的指令的预设次数越少。
在本发明一实施例中，确定模块701进一步配置为：基于调用请求在类文件库中查找与所述智能合约所对应的类文件。
在本发明一实施例中，确定模块701进一步配置为：获取调用请求中用于指示所述智能合约的标识信息；以及根据标识信息在类文件库中查找与智能合约所对应的类文件。
在本发明一实施例中，如图8所示，该用于在多节点系统中对智能合约进行处理的装置进一步包括：生成模块703，配置为根据调用请求中用于指示智能合约的标识信息生成满足该调用请求的类文件。
在本发明一实施例中，执行模块702进一步配置为：对类文件进行实例化，并且确定调用智能合约的调用请求中的函数和参数；以及基于经实例化的类文件以及函数和参数来执行调用请求所调用的智能合约。
在本发明一实施例中，如图9所示，该用于在多节点系统中对智能合约进行处理的装置进一步包括：第一验证模块704，配置为在基于针对待调用的智能合约的调用请求确定该智能合约所对应的类文件之前，确定调用智能合约的调用请求合法。
在本发明一实施例中，第一验证模块704进一步配置为：对调用请求的格式进行共识，当所有节点都认为调用请求的格式为合法时，确定调用请求合法。
在本发明一实施例中，如图10所示，该用于在多节点系统中对智能合约进行处理的装置进一步包括：部署模块705，配置为通过类加载器加载待部署的类文件；以及当确定类文件中并未包括非确定性类和/或非确定性函数时，部署类文件以形成类文件库。
在本发明一实施例中，部署模块705进一步配置为：当确定类文件中并未包括非确定性类和/或非确定性函数时，在类文件中设置与指令对应的计数器，其中，计数器用于在智能合约执行的过程中对指令的执行次数计数。
在本发明一实施例中，部署模块705进一步配置为：在本地节点处或在与本地节点通信连接的存储设备中部署类文件，以形成类文件库。
在本发明一实施例中，如图10所示，该用于在多节点系统中对智能合约进行处理的装置进一步包括：第二验证模块706，配置为在部署模块部署类文件之前，确定部署类文件的部署请求合法。
在本发明一实施例中，第二验证模块706进一步配置为：对部署请求的格式进行共识，当所有节点都认为部署请求的格式为合法时，确定调用请求合法。
应当理解，上述实施例所提供的用于在多节点系统中对智能合约进行处理的装置中记载的每个模块都与前述的用于在多节点系统中对智能合约进行处理的方法中的一个方法步骤相对应。由此，前述的方法步骤描述的操作和特征同样适用于该装置及其中所包含的对应的模块，重复的内容在此不再赘述。
图11为本发明一实施例提供的用于在多节点系统中对智能合约进行处理的装置的架构示意图。如图11所示，该处理装置300包括调用请求接收单元301、调用请求分析单元302、类文件选择单元303以及执行单元304。具体地，调用请求接收单元301被配置为被配置为接收针对智能合约的调用请求，并对所述调用请求进行合法性检验，以确定合法的调用请求。调用 请求分析单元302与调用请求接收单元301通信连接，并且被配置为对所述合法的调用请求进行分析，以获取所述合法的调用请求中的用于指示对应的智能合约的标识信息。类文件选择单元303被配置为基于所述标识信息来确定与所述合法的调用请求相对应的智能合约的类文件。基于该标识信息，类文件选择单元303将该标识信息与类文件库中的各个类文件的标识信息进行比较，进而选择对应于该合法的调用请求的类文件。执行单元304被配置为基于由类文件选择单元303所确定的类文件和调用请求来执行对应的智能合约。具体地，执行单元304对类文件进行实例化，并结合调用请求中的函数和参数，来实施对应于所述合法的调用请求的智能合约。
图12为本发明一实施例提供的一种在多节点系统中对智能合约进行部署的方法的流程示意图。如图12所示，该方法包括如下步骤：
步骤1201：获取部署请求，其中，该部署请求包括类文件，该类文件基于待部署的智能合约的程序逻辑预先编译而成。
步骤1202：当确定类文件中并未包括非确定性类和/或非确定性函数时，将类文件部署在多节点系统中。例如，部署在本地节点处或部署在与本地节点通信连接的存储设备中，以形成类文件库。
如果该类文件中存在任意一个类产生了对非确定性函数的调用，则停止部署该智能合约，进而提示部署失败。如果判别出该智能合约的类文件并未使用非确定性的函数，则部署该类文件。本领域的技术人员能够理解的是，在不同的应用中，可以存在不同方式的提示，譬如，将部署失败的结果返回给用户，从而告知(譬如，经由用户可视的界面)其所提交的智能合约无法部署到区块链中。
由此可见，通过这种类文件部署方式，可在将类文件预先部署在多节点系统中时，剔除包括非确定性类和/或非确定性函数的类文件，以保证可被执行的类文件都可实现确定性计算，满足当结合区块链技术来实现智能合约时的如下要求：在不同的节点上，在不同的时间，相同的输入可以得到相同的输出。
在本发明一实施例中，如图13所示，当考虑到既要满足智能合约的确定性计算要求，又要满足有限计算要求时，该在多节点系统中对智能合约进行部署的方法可进一步包括：当确定类文件中并未包括非确定性类和/或非确定性函数时，在类文件中设置与指令对应的计数器，其中，计数器用于在智能合约执行的过程中对指令的执行次数计数(步骤1301)。具体而言，可通过基于类加载器和字节码增强器来对智能合约的类文件进行处理，其中，类加载器用于判别加载的类文件是否含有非确定性的函数，并基于此能力拒绝加载含有非确定性函数的类；字节码增强器用于分析和修改类文件，在类文件被执行的过程中，对类文件中各个被调用的指令进行计数。编写好的智能合约经过编译后，将通过P2P或其它传输方式在多节点系统(譬如，区块链)中扩散，每个节点都会收到该智能合约的类文件。区块链中的节点(譬如，验证节点)会依据指定的规则对收到的类文件进行共识，或者将收到的合约先保存到内存中，等待新一轮的共识时间，触发对该份合约的共识和处理。可以理解的，本发明中的共识可以针对一个或多个类文件。
在本发明一实施例中，如图14所示，为了提高类文件部署操作的可靠性，在部署类文件之前，需要先确定部署该类文件的部署请求合法(步骤1401)。具体而言，接收到该部署请求的节点可对该部署请求进行合法性检验，以确定合法的部署请求。合法性检验是对该部署请求进行形式上的检验，也就是说，上述节点将对该部署请求的格式或其它参数进行检测，进而判断该部署请求是否是合法的部署请求，例如，判断该请求的格式是否适用于当前的区块链。可以理解的是，其它判断规则的合法性检验也适用。
在一进一步实施例中，对于区块链，上述合法性检验可以通过共识的机制来执行。具体而言，可对部署请求的格式进行共识，当所有节点都认为部署请求的格式为合法时，确定调用请求合法。通过PoW、PoS、PBFT或者其它共识算法，让多个接收到该部署请求的节点对该部署请求进行合法性检验，进而确定该部署请求对于当前的区块链是否为合法的部署请求。基于共识的结果，将产生不同的操作。具体而言，如果共识的结果指示该部署请求不是合法的部署 请求(譬如，该部署请求的格式不符合要求)，则结束该智能合约的部署；如果共识的结果指示该部署请求是合法的部署请求(譬如但不限于，该部署请求的格式符合该区块链对部署请求的格式要求)，则执行后续的类文件部署操作。
图15a为本发明一实施例提供的智能合约的部署方法的流程图。如图15所示，该智能合约的部署方法包括如下步骤：
步骤S1501：获取智能合约的部署请求。
在该步骤中，区块链中的多个节点将接收到智能合约的部署请求。在此实施例中，部署请求具有特定格式并且包括该智能合约的类文件(即，待部署类文件)。可以理解的，部署请求可以先由某个节点接收到，然后由该节点以P2P的方式发送到区块链中的多个节点。
步骤S1502，判断部署请求是否具备合法性。
在该步骤中，接收到该部署请求的节点将对该部署请求进行合法性检验，以确定合法的部署请求。在此实施例中，合法性检验是对该部署请求进行形式上的检验，也就说，上述节点将对该部署请求的格式或其它参数进行检测，进而判断该部署请求是否是合法的部署请求，例如，判断该请求的格式是否适用于当前的区块链。可以理解的是，其它判断规则的合法性检验也适用。
对于区块链，步骤S1502可以通过共识的机制来执行。具体而言，通过PoW、PoS、PBFT或者其它共识算法，让多个接收到该部署请求的节点对该部署请求进行合法性检验，进而确定该部署请求对于当前的区块链是否为合法的部署请求。
基于步骤S1502中的共识的结果，将产生不同的操作。具体而言，如果共识的结果指示该部署请求不是合法的部署请求(譬如，该部署请求的格式不符合要求)，则结束该智能合约的部署；如果共识的结果指示该部署请求是合法的部署请求(譬如但不限于，该部署请求的格式符合该区块链对部署请求的格式要求)，则执行步骤S1503中的操作。
步骤S1503：判断该部署请求是否存在非确定性。
由前述可知，该部署请求具有特定格式并且包括待部署的类文件。因此，可以通过例如类加载器来判别该待部署的类文件是否使用了非确定性的函数，如果该类文件中存在任意一个类产生了对非确定性函数的调用，则停止部署该智能合约，进而提示部署失败(步骤S1507)。如果类加载器判别出该智能合约的类文件并未使用非确定性的函数(即该类文件中并不包含非确定性类)，则执行步骤S1504中的操作。本领域的技术人员能够理解的是，在不同的应用中，可以存在不同方式的提示，譬如，将部署失败的结果返回给用户，从而告知(譬如，经由用户可视的界面)其所提交的智能合约无法部署到区块链中。
步骤S1504：添加计数器。
在该步骤中，将在指定的指令后面设置计数器，从而可以实现对调用的指令的计数，下面结合图15b对增加计数器后的类文件的执行进行阐述。
如图15b所示，类文件400在执行过程中将执行指令1的次数为1，执行指令2的次数为3。如前述，假设指令2为指定的指令，则指令2每执行一次，计数器便增加一次。如此，如果将对指令2的执行次数的阈值设置为大于等于4，则类文件400能够完全执行；反之，如果将对指令2的执行次数的阈值设置为2，则类文件400将无法完全执行或是输出提示错误的结果。
在一种实施方式中，还可以为不同指令赋予不同的“权重”。仍以图14b所示的指令为例，通过调整相应的指令的权重，可以对指令的执行次数进行相应地指定。譬如，通过提升指令2的权重，指令2被允许执行的次数将进一步地减少；同样，通过降低指令2的权重，指令2被允许执行的次数将得到提升。
因此，通过对指令的计数来防止某一用户/节点故意或因故障而产生对某一指令的大量重复的调用，保证了区块链的有限计算的特点。例如，在竞标系统中，通过在对应于撤回竞标操作的指令的后面增添计数器，可以防止用户恶意地反复撤回竞标，避免整个竞标系统的因某一个用户的操作而导致瘫痪或无法正常工作。可以理解的，计数器可以根据具体的应用而设置于不同的位置。
步骤1505：存储经修改的类文件。
由前一步骤可知，未经修改的待部署类文件不含有计数器，本实施例通过字节码增强技术来对类文件进行修改，从而在所指定的指令后面增添计数器。经修改的待部署类文件，将被存储于指定的位置(譬如，存储在区块链的节点处或存储在与该节点通信连接的存储设备中)，从而实现将待部署类文件部署到类文件库中，完成类文件库的构建。
待上述存储步骤完成后，将执行步骤S1506：提示部署成功。譬如，将部署成功的结果返回给用户，从而在用户可视的界面上告知其所提交的智能合约已经部署到了区块链中。
通过上述步骤，实现了对智能合约的类文件的部署，并且使得区块链中的类文件均具有确定性和有限性，从而提升了网络的稳定性。具体而言，通过基于类文件是否包括非确定性类和/或非确定性函数或非确定性类来针对待部署的类文件进行筛选，进而使得筛选后且被保留的类文件均具备确定性。另外，由于经修改后的类文件的指定的指令后设置有计数器，因此，当针对该指令的调用次数设置一阈值时，通过比较计数器的输出值和该调用次数的阈值，则可以限制该指令的调用次数，进而使得该类文件在被调用时具备有限计算的特点。
图16所示为本发明一实施例提供的一种在多节点系统中对智能合约进行部署的装置的结构示意图。如图16所示，该装置包括：
获取模块1601，配置为获取部署请求，其中，该部署请求包括类文件，该类文件基于待部署的智能合约的程序逻辑预先编译而成；以及
部署执行模块1602，配置为当确定类文件中并未包括非确定性类和/或非确定性函数时，将类文件部署在多节点系统中。
在本发明一实施例中，部署执行模块1602进一步配置为：当确定类文件中并未包括非确定性类和/或非确定性函数时，在类文件中设置与指令对应的计数器，其中，计数器用于在智能合约执行的过程中对指令的执行次数计数。
在本发明一实施例中，部署执行模块1602进一步配置为：在本地节点处或在与本地节点通信连接的存储设备中部署类文件，以形成类文件库。
在本发明一实施例中，如图17所示，该在多节点系统中对智能合约进行部署的装置进一步包括：第三验证模块1603，配置为在部署类文件之前，确定部署类文件的部署请求合法。
在本发明一实施例中，第三验证模块1603进一步配置为：对部署请求的格式进行共识，当所有节点都认为部署请求的格式为合法时，确定调用请求合法。
应当理解，上述实施例所提供的用于在多节点系统中对智能合约进行部署的装置中记载的每个模块都与前述的用于在多节点系统中对智能合约进行部署的方法中的一个方法步骤相对应。由此，前述的方法步骤描述的操作和特征同样适用于该装置及其中所包含的对应的模块，重复的内容在此不再赘述。
应当理解，如前任一种方法的流程还可实现为机器可读指令，该机器可读指令包括由处理器执行的程序。该程序可被实体化在被存储于有形计算机可读介质的软件中，该有形计算机可读介质如CD-ROM、软盘、硬盘、数字通用光盘(DVD)、蓝光光盘或其它形式的存储器。替代的，如前任一种方法中的一些步骤或所有步骤可利用专用集成电路(ASIC)、可编程逻辑器件(PLD)、现场可编程逻辑器件(EPLD)、离散逻辑、硬件、固件等的任意组合被实现。另外，虽然与前述任一方法相对应的说的流程图描述了该数据处理方法，但可对该处理方法中的步骤进行修改、删除或合并。
如上所述，可利用编码指令(如计算机可读指令)来实现如前任一种方法的过程，该编程指令存储于有形计算机可读介质上，如硬盘、闪存、只读存储器(ROM)、光盘(CD)、数字通用光盘(DVD)、高速缓存器、随机访问存储器(RAM)和/或任何其他存储介质，在该存储介质上信息可以存储任意时间(例如，长时间，永久地，短暂的情况，临时缓冲，和/或信息的缓存)。如在此所用的，该术语有形计算机可读介质被明确定义为包括任意类型的计算机可读存储的信号。附加地或替代地，可利用编码指令(如计算机可读指令)实现如前任一种方法的示例过程，该编码指令存储于非暂时性计算机可读介质，如硬盘，闪存，只读存储器，光盘，数字通用光盘，高速缓存器，随机访问存储器和/或任何其他存储介质，在该存储介质信息可以存储任意时间(例如，长时间，永久地，短暂的情况，临时缓冲，和/或信息的缓存)。
本发明支持Java语言开发智能合约，同时具有确定性计算、有限计算的特点，不需要额外开发编译器、解释器，基本保留了Java语言的所有功能，易于接入使用。
因此，虽然参照特定的示例来描述了本发明，其中这些特定的示例仅仅旨在是示例性的，而不是对本发明进行限制，但对于本领域普通技术人员来说显而易见的是，在不脱离本发明的精神和保护范围的基础上，可以对所公开的实施例进行改变、增加或者删除。

Claims (39)

  1. 一种用于在多节点系统中对智能合约进行处理的方法，其特征在于，包括：
    基于针对待调用的智能合约的调用请求确定所述智能合约所对应的类文件；以及
    基于所述类文件执行所述智能合约；
    其中，所述类文件基于所述智能合约的程序逻辑预先编译而成。
  2. 根据权利要求1所述的方法，其特征在于，所述类文件包括指令和与所述指令相对应的计数器；
    其中，所述基于所述类文件执行所述智能合约包括：
    利用所述计数器对所述指令的执行次数进行计数，当所述执行次数大于预设次数时，停止执行所述指令。
  3. 根据权利要求1或2所述的方法，其特征在于，所述类文件包括多个所述指令，每个所述指令设置有对应的权重；
    其中，所述权重的值越大，与所述权重对应的所述指令的所述预设次数越少。
  4. 根据权利要求1至3中任一所述的方法，其特征在于，所述基于针对待调用的智能合约的调用请求确定所述智能合约所对应的类文件包括：
    基于所述调用请求在类文件库中查找与所述智能合约所对应的类文件。
  5. 根据权利要求4所述的方法，其特征在于，所述基于所述调用请求在类文件库中查找与待调用的所述智能合约所对应的类文件，包括：
    获取所述调用请求中用于指示所述智能合约的标识信息；以及
    根据所述标识信息在所述类文件库中查找与所述智能合约所对应的类文件。
  6. 根据权利要求1至3中任一所述的方法，其特征在于，所述基于针对待调用的智能合约的调用请求确定所述待调用的智能合约所对应的类文件包括：
    根据所述调用请求中用于指示所述智能合约的标识信息生成满足所述调用请求的所述类文件。
  7. 如权利要求1至6中任一所述的方法，其特征在于，所述基于所述类文件执行所述智能合约包括：
    对所述类文件进行实例化，并且确定所述调用请求中的函数和参数；以及
    基于经实例化的所述类文件以及所述函数和参数来执行所述智能合约。
  8. 如权利要求1至7中任一所述的方法，其特征在于，在基于针对待调用的智能合约的调用请求确定所述智能合约所对应的类文件之前，进一步包括：
    确定所述调用请求合法。
  9. 如权利要求8所述的方法，其特征在于，所述确定所述调用请求合法包括：
    对所述调用请求的格式进行共识，当所有节点都认为所述调用请求的格式为合法时，确定所述调用请求合法。
  10. 根据权利要求1至9中任一所述的方法，其特征在于，所述类文件预先部署在所述多节点系统中，其中，所述类文件的部署过程包括：
    通过类加载器加载待部署的所述类文件；以及
    当确定所述类文件中并未包括非确定性类和/或非确定性函数时，部署所述类文件以形成类文件库。
  11. 根据权利要求10所述的方法，其特征在于，所述类文件的部署过程进一步包括：
    当确定所述类文件中并未包括非确定性类和/或非确定性函数时，在所述类文件中设置与指令对应的计数器，其中，所述计数器用于在所述智能合约执行的过程中对所述指令的执行次数计数。
  12. 根据权利要求10至11中任一所述的方法，其特征在于，在部署所述类文件之前，进一步包括：
    确定部署所述类文件的部署请求合法。
  13. 根据权利要求12所述的方法，其特征在于，所述确定部署所述类文件的部署请求合法包括：对所述部署请求的格式进行共识，当所有节点都认为所述部署请求的格式为合法时，确定所述调用请求合法。
  14. 一种用于在多节点系统中对智能合约进行处理的装置，其特征在于，包括：
    确定模块，配置为基于针对待调用的智能合约的调用请求确定所述智能合约所对应的类文件；以及
    执行模块，配置为基于所述类文件执行所述待调用的智能合约；
    其中，所述类文件基于所述待调用的智能合约的程序逻辑预先编译而成。
  15. 根据权利要求14所述的装置，其特征在于，所述类文件包括指令和与所述指令相对应的计数器；
    其中，所述执行模块进一步配置为：
    利用所述计数器对所述指令的执行次数进行计数，当所述执行次数大于预设次数时，停止执行所述指令。
  16. 根据权利要求15所述的装置，其特征在于，所述类文件包括多个所述指令，每个所述指令设置有对应的权重；
    其中，所述权重的值越大，与所述权重对应的所述指令的所述预设次数越少。
  17. 根据权利要求14至16中任一所述的装置，其特征在于，所述确定模块进一步配置为：
    基于所述调用请求在类文件库中查找与所述智能合约所对应的类文件。
  18. 根据权利要求17所述的装置，其特征在于，所述确定模块进一步配置为：获取所述调用请求中用于指示所述智能合约的标识信息；以及根据所述标识信息在所述类文件库中查找与所述智能合约所对应的类文件。
  19. 根据权利要求14至18中任一所述的装置，其特征在于，进一步包括：
    生成模块，配置为根据所述调用请求中用于指示所述智能合约的标识信息生成满足所述调用请求的所述类文件。
  20. 如权利要求14至19中任一所述的装置，其特征在于，所述执行模块进一步配置为：对所述类文件进行实例化，并且确定调用所述智能合约的调用请求中的函数和参数；以及基于经实例化的所述类文件以及所述函数和参数来执行所述调用请求所调用的所述智能合约。
  21. 如权利要求14至20中任一所述的装置，其特征在于，进一步包括：
    第一验证模块，配置为在基于针对待调用的智能合约的调用请求确定所述智能合约所对应的类文件之前，确定调用所述智能合约的调用请求合法。
  22. 如权利要求21所述的装置，其特征在于，所述第一验证模块进一步配置为：对所述调用请求的格式进行共识，当所有节点都认为所述调用请求的格式为合法时，确定所述调用请求合法。
  23. 根据权利要求14至22中任一所述的装置，其特征在于，进一步包括：
    部署模块，配置为通过类加载器加载待部署的所述类文件；以及当确定所述类文件中并未包括非确定性类和/或非确定性函数时，部署所述类文件以形成类文件库。
  24. 根据权利要求23所述的装置，其特征在于，所述部署模块进一步配置为：当确定所述类文件中并未包括非确定性类和/或非确定性函数时，在所述类文件中设置与指令对应的计数器，其中，所述计数器用于在所述智能合约执行的过程中对所述指令的执行次数计数。
  25. 根据权利要求23或24所述的装置，其特征在于，所述部署模块进一步配置为：在本地节点处或在与所述本地节点通信连接的存储设备中部署所述类文件，以形成类文件库。
  26. 根据权利要求23至25中任一所述的装置，其特征在于，进一步包括：
    第二验证模块，配置为在所述部署模块部署所述类文件之前，确定部署所述类文件的部署请求合法。
  27. 根据权利要求26所述的装置，其特征在于，所述第二验证模块进一步配置为：对所述部署请求的格式进行共识，当所有节点都认为所述部署请求的格式为合法时，确定所述调用 请求合法。
  28. 一种在多节点系统中对智能合约进行部署的方法，其特征在于，包括：
    获取部署请求，其中，所述部署请求包括类文件，所述类文件基于待部署的智能合约的程序逻辑预先编译而成；以及
    当确定所述类文件中并未包括非确定性类和/或非确定性函数时，将所述类文件部署在所述多节点系统中。
  29. 根据权利要求28所述的方法，其特征在于，所述类文件的部署过程进一步包括：
    当确定所述类文件中并未包括非确定性类和/或非确定性函数时，在所述类文件中设置与指令对应的计数器，其中，所述计数器用于在所述智能合约执行的过程中对所述指令的执行次数计数。
  30. 根据权利要求28或29所述的方法，其特征在于，所述类文件部署在本地节点处或部署在与所述本地节点通信连接的存储设备中，以形成类文件库。
  31. 根据权利要求28至30中任一所述的方法，其特征在于，在部署所述类文件之前，进一步包括：
    确定部署所述类文件的部署请求合法。
  32. 根据权利要求31所述的方法，其特征在于，所述确定部署所述类文件的部署请求合法包括：对所述部署请求的格式进行共识，当所有节点都认为所述部署请求的格式为合法时，确定所述调用请求合法。
  33. 一种在多节点系统中对智能合约进行部署的装置，其特征在于，包括：
    获取模块，配置为获取部署请求，其中，所述部署请求包括类文件，所述类文件基于待部署的智能合约的程序逻辑预先编译而成；以及
    部署执行模块，配置为当确定所述类文件中并未包括非确定性类和/或非确定性函数时，将所述类文件部署在所述多节点系统中。
  34. 根据权利要求33所述的装置，其特征在于，所述部署执行模块进一步配置为：当确定所述类文件中并未包括非确定性类和/或非确定性函数时，在所述类文件中设置与指令对应的计数器，其中，所述计数器用于在所述智能合约执行的过程中对所述指令的执行次数计数。
  35. 根据权利要求33或34所述的装置，其特征在于，所述部署执行模块进一步配置为：在本地节点处或在与所述本地节点通信连接的存储设备中部署所述类文件，以形成类文件库。
  36. 根据权利要求33至35中任一所述的装置，其特征在于，第三验证模块，配置为在部署所述类文件之前，确定部署所述类文件的部署请求合法。
  37. 根据权利要求36所述的装置，其特征在于，所述第三验证模块进一步配置为：对所述部署请求的格式进行共识，当所有节点都认为所述部署请求的格式为合法时，确定所述调用请求合法。
  38. 一种计算机设备，包括存储器、处理器以及存储在所述存储器上被所述处理器执行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至13以及28至32中任一项所述方法的步骤。
  39. 一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至13以及28至32中任一项所述方法的步骤。
PCT/CN2018/095784 2017-07-31 2018-07-16 智能合约处理方法及装置 WO2019024674A1 (zh)

Priority Applications (5)

Application Number Priority Date Filing Date Title
KR1020197019035A KR20190107664A (ko) 2017-07-31 2018-07-16 스마트 계약 처리 방법 및 장치
SG11201907111QA SG11201907111QA (en) 2017-07-31 2018-07-16 Method and device for processing smart contracts
JP2019524456A JP2019536153A (ja) 2017-07-31 2018-07-16 スマート・コントラクト処理方法及び装置
AU2018310287A AU2018310287A1 (en) 2017-07-31 2018-07-16 Smart contract processing method and apparatus
US16/460,202 US20190324772A1 (en) 2017-07-31 2019-07-02 Method and device for processing smart contracts

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710638423.X 2017-07-31
CN201710638423.XA CN107392619B (zh) 2017-07-31 2017-07-31 智能合约处理方法及装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/460,202 Continuation US20190324772A1 (en) 2017-07-31 2019-07-02 Method and device for processing smart contracts

Publications (1)

Publication Number Publication Date
WO2019024674A1 true WO2019024674A1 (zh) 2019-02-07

Family

ID=60342494

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/095784 WO2019024674A1 (zh) 2017-07-31 2018-07-16 智能合约处理方法及装置

Country Status (8)

Country Link
US (1) US20190324772A1 (zh)
JP (1) JP2019536153A (zh)
KR (1) KR20190107664A (zh)
CN (1) CN107392619B (zh)
AU (1) AU2018310287A1 (zh)
SG (1) SG11201907111QA (zh)
TW (1) TW201911032A (zh)
WO (1) WO2019024674A1 (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112636981A (zh) * 2020-12-28 2021-04-09 杭州趣链科技有限公司 区块链主机及其代理方法、装置及存储介质
US20210191702A1 (en) * 2018-10-12 2021-06-24 Alibaba Group Holding Limited Blockchain Node Service Deployment Method, Apparatus and System, and Computing Device and Medium
CN113342429A (zh) * 2021-06-09 2021-09-03 网易（杭州）网络有限公司 智能合约数据处理方法、装置、计算机设备及存储介质
CN113805889A (zh) * 2021-08-27 2021-12-17 成都质数斯达克科技有限公司 一种智能合约调用执行方法、装置、设备及可读存储介质
JP2022541929A (ja) * 2019-09-24 2022-09-28 京▲東▼科技信息技▲術▼有限公司 スマートコントラクトを発行するための方法及び装置

Families Citing this family (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9918605B2 (en) 2015-04-09 2018-03-20 Irobot Corporation Wall following robot
CN107392619B (zh) * 2017-07-31 2020-12-29 众安信息技术服务有限公司 智能合约处理方法及装置
CN108776936A (zh) * 2018-06-05 2018-11-09 中国平安人寿保险股份有限公司 保险理赔方法、装置、计算机设备和存储介质
CN109146679B (zh) 2018-06-29 2023-11-10 创新先进技术有限公司 基于区块链的智能合约调用方法及装置、电子设备
CN108916604B (zh) * 2018-07-04 2020-07-03 临沂大学 一种便于维护的智能合约转换器
US11842322B2 (en) * 2018-08-22 2023-12-12 Equinix, Inc. Smart contract interpreter
CN109067759B (zh) * 2018-08-27 2020-11-03 深圳前海益链网络科技有限公司 一种智能合约调用单点执行系统
CN109376541A (zh) * 2018-09-21 2019-02-22 上海点融信息科技有限责任公司 用于运行智能合约的方法、装置以及计算机存储介质
CN109933404B (zh) * 2018-12-12 2020-05-12 阿里巴巴集团控股有限公司 一种基于区块链智能合约的编解码方法及系统
US10733152B2 (en) 2018-12-29 2020-08-04 Alibaba Group Holding Limited System and method for implementing native contract on blockchain
KR102237015B1 (ko) * 2018-12-29 2021-04-07 어드밴스드 뉴 테크놀로지스 씨오., 엘티디. 블록체인 상의 네이티브 계약을 구현하기 위한 시스템 및 방법
CN109710385A (zh) * 2018-12-29 2019-05-03 杭州趣链科技有限公司 一种基于Java虚拟机的智能合约复杂度限制方法
SG11201908890XA (en) * 2019-03-26 2019-10-30 Alibaba Group Holding Ltd System and method for implementing different types of blockchain contracts
CN110188097A (zh) * 2019-04-19 2019-08-30 阿里巴巴集团控股有限公司 区块链中智能合约的存储、执行方法及装置和电子设备
CN110119428B (zh) * 2019-04-19 2023-05-12 腾讯科技（深圳）有限公司 一种区块链信息管理方法、装置、设备及存储介质
WO2019170175A2 (en) * 2019-06-28 2019-09-12 Alibaba Group Holding Limited System and method for executing different types of blockchain contracts
US10783082B2 (en) * 2019-08-30 2020-09-22 Alibaba Group Holding Limited Deploying a smart contract
CN110675256B (zh) * 2019-08-30 2020-08-21 阿里巴巴集团控股有限公司 部署和执行智能合约的方法及装置
CN110633328B (zh) * 2019-09-25 2024-03-22 腾讯云计算（北京）有限责任公司 一种信息处理方法、装置及计算机可读存储介质
CN111160911B (zh) * 2019-12-31 2023-10-24 杭州趣链科技有限公司 一种面向区块链的智能合约调用频率控制方法
US11893002B2 (en) * 2020-05-04 2024-02-06 Salesforce, Inc. System or method to run distributed validation of workflows across a network in a shared distributed ledger in multi-tenant cloud environment
CN111831745B (zh) * 2020-06-05 2023-04-18 广东科学技术职业学院 定时智能合约的调度方法及装置
CN111815330A (zh) * 2020-08-31 2020-10-23 支付宝(杭州)信息技术有限公司 一种部署智能合约的方法、区块链节点和存储介质
CN112070618A (zh) * 2020-09-02 2020-12-11 中国平安人寿保险股份有限公司 基于区块链的保险核赔方法、装置、设备及介质
CN112162851B (zh) * 2020-09-14 2022-12-13 Oppo（重庆）智能科技有限公司 dex预编译方法、装置、计算机设备及存储介质
CN112417514B (zh) * 2020-10-30 2024-04-05 迅鳐成都科技有限公司 基于电子合约的多方数据协作方法、系统及存储介质
CN112346820A (zh) * 2020-11-16 2021-02-09 杭州复杂美科技有限公司 区块链jvm应用方法、设备和存储介质
CN112445543B (zh) * 2020-11-26 2023-03-10 杭州趣链科技有限公司 智能合约的类调用方法、装置及电子设备
CN112765676B (zh) * 2020-12-03 2024-07-12 杭州趣链科技有限公司 一种智能合约执行方法、智能合约执行装置及节点设备
CN112968930B (zh) * 2021-01-29 2022-08-19 东南大学 区块链键值对智能合约及其设计方法
CN112950237B (zh) * 2021-05-12 2021-08-06 常州市市场监管服务中心(常州市特种设备事故调查处置中心) 基于ocr和区块链的气瓶质量安全追溯系统及控制方法
CN113778564B (zh) * 2021-09-03 2023-05-30 杭州复杂美科技有限公司 一种高效执行evm智能合约的方法、设备及储存介质
CN114422535B (zh) * 2022-01-18 2024-04-09 网易（杭州）网络有限公司 区块链中部署合约的方法、装置、计算机设备及存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1645319A (zh) * 2005-01-20 2005-07-27 上海交通大学 优化网络环境下部分计值服务的方法
CN1710536A (zh) * 2005-06-30 2005-12-21 西安交通大学 一种应用服务器平台的实现方法
CN104731708A (zh) * 2015-03-25 2015-06-24 北京信息控制研究所 一种Shellcode的动态检测方法
CN106101242A (zh) * 2016-06-24 2016-11-09 深圳前海微众银行股份有限公司 区块链云服务平台的构建方法和装置
CN107392619A (zh) * 2017-07-31 2017-11-24 众安信息技术服务有限公司 智能合约处理方法及装置

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150379510A1 (en) * 2012-07-10 2015-12-31 Stanley Benjamin Smith Method and system to use a block chain infrastructure and Smart Contracts to monetize data transactions involving changes to data included into a data supply chain.
CN106295336B (zh) * 2015-06-26 2020-05-22 阿里巴巴集团控股有限公司 恶意程序检测方法及装置
CN108027867A (zh) * 2015-07-14 2018-05-11 Fmr有限责任公司 计算高效的转账处理、审计以及搜索装置、方法和系统
CN105893042A (zh) * 2016-03-31 2016-08-24 北京航空航天大学 一种基于区块链的智能合约的实现方法
CN106651303B (zh) * 2016-12-02 2020-05-26 北京轻信科技有限公司 一种基于模板的智能合约处理方法和系统
CN106874087A (zh) * 2017-01-25 2017-06-20 上海钜真金融信息服务有限公司 一种区块链智能合约定时任务调度方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1645319A (zh) * 2005-01-20 2005-07-27 上海交通大学 优化网络环境下部分计值服务的方法
CN1710536A (zh) * 2005-06-30 2005-12-21 西安交通大学 一种应用服务器平台的实现方法
CN104731708A (zh) * 2015-03-25 2015-06-24 北京信息控制研究所 一种Shellcode的动态检测方法
CN106101242A (zh) * 2016-06-24 2016-11-09 深圳前海微众银行股份有限公司 区块链云服务平台的构建方法和装置
CN107392619A (zh) * 2017-07-31 2017-11-24 众安信息技术服务有限公司 智能合约处理方法及装置

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210191702A1 (en) * 2018-10-12 2021-06-24 Alibaba Group Holding Limited Blockchain Node Service Deployment Method, Apparatus and System, and Computing Device and Medium
US11604631B2 (en) * 2018-10-12 2023-03-14 Alibaba Group Holding Limited Blockchain node service deployment method, apparatus and system and computing device and medium
JP2022541929A (ja) * 2019-09-24 2022-09-28 京▲東▼科技信息技▲術▼有限公司 スマートコントラクトを発行するための方法及び装置
CN112636981A (zh) * 2020-12-28 2021-04-09 杭州趣链科技有限公司 区块链主机及其代理方法、装置及存储介质
CN113342429A (zh) * 2021-06-09 2021-09-03 网易（杭州）网络有限公司 智能合约数据处理方法、装置、计算机设备及存储介质
CN113342429B (zh) * 2021-06-09 2023-08-08 网易（杭州）网络有限公司 智能合约数据处理方法、装置、计算机设备及存储介质
CN113805889A (zh) * 2021-08-27 2021-12-17 成都质数斯达克科技有限公司 一种智能合约调用执行方法、装置、设备及可读存储介质

Also Published As

Publication number Publication date
SG11201907111QA (en) 2019-09-27
KR20190107664A (ko) 2019-09-20
CN107392619B (zh) 2020-12-29
TW201911032A (zh) 2019-03-16
US20190324772A1 (en) 2019-10-24
AU2018310287A1 (en) 2019-09-05
JP2019536153A (ja) 2019-12-12
CN107392619A (zh) 2017-11-24

Similar Documents

Publication Publication Date Title
WO2019024674A1 (zh) 智能合约处理方法及装置
CN110941528B (zh) 一种基于故障的日志埋点设置方法、装置及系统
US20160092350A1 (en) Callpath finder
CN110058864B (zh) 微服务的部署方法及装置
US7552422B2 (en) Test case inheritance controlled via attributes
US11556348B2 (en) Bootstrapping profile-guided compilation and verification
US9804962B2 (en) Garbage collection control in managed code
US10466985B2 (en) Hybrid deoptimization mechanism for class hierarchy analysis
US20170048008A1 (en) Method and apparatus for verification of network service in network function virtualization environment
US9336020B1 (en) Workflows with API idiosyncrasy translation layers
US10884764B1 (en) Optimizing managed runtime applications for serverless environments
EP3607432B1 (en) Flow-based scoping
US7340725B1 (en) Smart test attributes and test case scenario in object oriented programming environment
WO2021146988A1 (en) Method and apparatus for protecting smart contracts against attacks
US7577541B1 (en) Test services provider
CN113010892B (zh) 小程序恶意行为检测方法和装置
US10120777B1 (en) Remediating serialization incompatibilities
US9430196B2 (en) Message inlining
US8739136B2 (en) Validating run-time references
US7082376B1 (en) State full test method executor
CA2543989C (en) System and method for generating safe and efficient component relationships in wireless applications
Greci et al. A framework for contract-policy matching based on symbolic simulations for securing mobile device application
CN112416312B (zh) 一种对象获取方法、装置及电子设备、存储介质
CN117149263A (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: 18842269

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2019524456

Country of ref document: JP

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 20197019035

Country of ref document: KR

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2018310287

Country of ref document: AU

Date of ref document: 20180716

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 29.05.2020)

122 Ep: pct application non-entry in european phase

Ref document number: 18842269

Country of ref document: EP

Kind code of ref document: A1