Patent Grant
11010303
One or more implementations of the present specification relate to the field of blockchain technologies, and in particular, to a method and an apparatus for deploying a smart contract in a blockchain and a method and an apparatus for executing a smart contract in a blockchain.
Currently, increasingly more blockchain platforms support smart contracts to implement richer transactions. A smart contract is a transaction contract that can be executed automatically. The smart contract is digitally written to a blockchain, and the whole process of storage, reading, and execution is transparent, traceable, and tamper-resistant thanks to features of blockchain technologies. In addition, a state machine system is constructed by using a consensus algorithm in the blockchain, so that the smart contract can run efficiently. For example, Ethereum provides an open source blockchain platform, and allows developers to develop various blockchain applications and write smart contracts based on the system by providing a plurality of interfaces.
Therefore, the blockchain platform can allow users to implement transactions with richer content, thereby providing richer functions. Correspondingly, increasing data storage and program applications (for example, a distributed application (Dapp)) are implemented by using the blockchain. Correspondingly, a virtual machine is disposed in each node in the blockchain to execute a smart contract in the blockchain, and a consensus mechanism is used to ensure that virtual machines in nodes have the same execution status and execution result. Therefore, execution efficiency of the smart contract becomes a main performance indicator of the blockchain platform.
One or more implementations of the present specification describe a method and an apparatus for deploying a smart contract and a method and an apparatus for executing a smart contract, to improve execution efficiency in either contract invocation phase, execution phase, or both and improve platform performance by preprocessing a bytecode of a smart contract in a deployment phase.
According to a first aspect, a method for deploying a smart contract is provided, and the method is performed by a virtual machine of any node in a blockchain network, and includes: obtaining, in response to a request for deploying a first contract, a bytecode included in a contract module corresponding to the first contract; parsing the bytecode into executable instruction codes, and storing the executable instruction codes in a cache memory; determining a function index table for import and export functions in the bytecode, where the function index table is used to indicate a memory address of an instruction code corresponding to each of the import and export functions; and storing the function index table in the cache memory.
In an implementation, the request for deploying the first contract is to create a first transaction of the first contract; and the obtaining a bytecode included in a contract module corresponding to the first contract includes: extracting the bytecode from a data field of the first transaction.
According to an implementation, the bytecode is encoded by using a first coding protocol, and the first coding protocol is a variable-length coding protocol; and in this case, the parsing process can include: decoding the bytecode by using a decoding protocol corresponding to the first coding protocol, and converting a variable-length instruction into a memory-aligned fixed-length instruction.
According to a specific implementation, the contract module is a WASM module, and the first coding protocol is a leb 128 coding protocol.
In an implementation, in the case of a variable-length coding protocol, the parsing process further includes: modifying a target address in a control transfer instruction based on a memory-aligned instruction storage location.
In an implementation, the function index table includes a first index table and a second index table, the first index table includes a mapping relationship between a function name of each of the import and export functions and a function index number, and the second index table includes a mapping relationship between a function index number and a memory address.
According to a second aspect, a method for executing a smart contract is provided, and the method is performed by a virtual machine of any node in a blockchain network, and includes: receiving a transaction request for invoking a first contract, where the transaction request includes a contract address and an invocation function of the first contract; obtaining, from a cache memory, an instruction code and a function index table that correspond to the first contract and are stored in the cache memory during a phase of deploying the first contract, where the function index table is used to indicate a memory address of an instruction code corresponding to each of import and export functions in the first contract; determining a memory address corresponding to the invocation function based on the function index table; and executing an instruction code in the memory address based on the determined memory address.
In an implementation, the function index table includes a first index table and a second index table, the first index table includes a mapping relationship between a function name of each of the import and export functions and a function index number, and the second index table includes a mapping relationship between a function index number and a memory address; and in this case, the memory address corresponding to the invocation function is determined in the following way: searching the first index table based on a function name of the invocation function, to determine an index number corresponding to the invocation function; and searching the second index table by using the determined index number, to determine the corresponding memory address.
According to a third aspect, an apparatus for deploying a smart contract is provided, the apparatus is deployed in a virtual machine of any node in a blockchain network, and the apparatus includes: a bytecode acquisition unit, configured to obtain, in response to a request for deploying a first contract, a bytecode included in a contract module corresponding to the first contract; a parsing unit, configured to parse the bytecode into executable instruction code, and store the executable instruction codes in a cache memory; an index table determining unit, configured to determine a function index table for import and export functions in the bytecode, where the function index table is used to indicate a memory address of an instruction code corresponding to each of the import and export functions; and an index table caching unit, configured to store the function index table in the cache memory.
According to a fourth aspect, an apparatus for executing a smart contract is provided, and the apparatus is deployed in a virtual machine of any node in a blockchain network, and includes: a request receiving unit, configured to receive a transaction request for invoking a first contract, where the transaction request includes a contract address and an invocation function of the first contract; an acquisition unit, configured to obtain, from a cache memory, an instruction code and a function index table that correspond to the first contract and are stored in the cache memory during a phase of deploying the first contract, where the function index table is used to indicate a memory address of an instruction code corresponding to each of import and export functions in the first contract; a determining unit, configured to determine a memory address corresponding to the invocation function based on the function index table; and an execution unit, configured to execute an instruction code in the memory address based on the determined memory address.
According to a fifth aspect, a computer readable storage medium is provided, where the computer readable storage medium stores a computer program, and when the computer program is executed in a computer, the computer is enabled to perform the methods in the first aspect and the second aspect.
According to a sixth aspect, a computing device is provided, and includes a memory and a processor, where the memory stores executable code, and when the processor executes the executable code, the methods in the first aspect and the second aspect are implemented.
According to the method and the apparatus provided in some implementations of the present specification, in a phase of deploying a smart contract, a corresponding bytecode is preprocessed, where the preprocessing includes parsing and decoding, and import and export functions are orchestrated, to generate a data structure needed for running. When the smart contract is invoked, execution can be directly performed based on the data structure, and no operations such as parsing, decoding, and target address modification are needed, thereby greatly improving execution efficiency. In addition, many smart contracts are repeatedly invoked and executed. A data structure generated during deployment can be reused by using the previous preprocessing solution. In other words, for each invoked smart contract, one parsing of the smart contract can facilitate multiple execution of the smart contract. As such, contract execution efficiency is further improved, and overall performance of a blockchain platform is also improved.
To describe the technical solutions in some implementations of the present disclosure more clearly, the following briefly describes the accompanying drawings needed for describing the implementations. Apparently, the accompanying drawings in the following description merely show some implementations of the present disclosure, and a person of ordinary skill in the art can further derive other drawings from these accompanying drawings without creative efforts.
The following describes the solutions provided in the present specification with reference to the accompanying drawings.
A person skilled in the art knows that a blockchain network includes several nodes, and the nodes can communicate with each other. A user can initiate a transaction by using the node and an external account. The transaction can be a common transfer transaction, or can be used to create a smart contract or invoke a smart contract.
A character string s is obtained as data to be published postData based on the contract.
Bob can write the smart contract in a high-level language, then compile the high-level language into a bytecode file by using a compiler, and then publish the contract in the form of a transaction. Specifically, Bob can initiate a transaction. In content of the transaction, a from field is set to Bob (or more specifically, an address of Bob), and a to field is set to a null value. In addition, the content of the transaction further includes a data field, and the data field includes code obtained after the smart contract is compiled into a bytecode.
After Bob publishes such a transaction in the blockchain network, each node in the blockchain network can obtain the bytecode of the smart contract. Therefore, the smart contract is deployed in each node in the blockchain network. As it is similar to a conventional transaction, an accounting node verifies, seals, etc. the transaction, records the transaction in a block, and adds the block to a blockchain by using a consensus mechanism. In this process, a contract address, for example, 0x6f . . . , is further assigned to the smart contract based on a certain algorithm, for example, hash is performed based on the address of the publisher. Therefore, one smart contract corresponds to one contract address, which is the same as an external account address of a user in form.
Any user in the blockchain network can invoke the smart contract after the smart contract is added to the blockchain.
Specifically, in content of the transaction, a from field can represent an address of caller Alice, a to field represents the contract address 0x6f . . . of the previous PostingData contract, and a transaction (Tx) field represents the smart contract to be invoked by using the transaction. A data field includes a method or a function name (set) and imported parameters (“Ant Forest, Green Charity”) in the contract to be invoked.
After receiving the transaction, other nodes perform an operation corresponding to contract logic by using an Ethereum virtual machine (EVM), and change a contract status in the network by using a consensus mechanism. Then, when viewing a variable of the contract, any node in the network finds that a value of postData in the contract becomes “Ant Forest, Green Charity”.
It can be seen from the previous process that when a smart contract is published, a bytecode obtained after the smart contract is compiled is deployed in each node. The bytecode is an intermediate code format, and includes a sequence of operation codes (opcode)/binary character codes including data pairs. When an account calls the smart contract, a virtual machine loads and runs the bytecode. More specifically, an interpreter in the virtual machine interprets and executes an instruction stream represented by the bytecode, to execute the smart contract and change a status of a parameter in the contract. Therefore, efficiency of interpretation and execution of a bytecode file by the virtual machine determines execution efficiency of the smart contract, which further determines performance of a blockchain platform.
To improve execution efficiency of a smart contract, in an implementation of the present specification, in a phase of deploying a smart contract, each node preprocesses and parses a contract module/file, generates a data structure needed for running, and stores the data structure in a cache memory. When the smart contract needs to be executed, the data structure that has been parsed can be directly obtained from the cache memory, and therefore the smart contract can be directly executed based on the data structure, thereby greatly improving execution efficiency of the smart contract. The following describes a specific implementation of the concept.
First, in step 31, the bytecode included in the contract module corresponding to the first contract is obtained in response to the request for deploying the first contract.
It can be understood that the first contract can be a smart contract to be deployed with any content. The smart contract usually can be written in a high-level language, and is compiled into the bytecode by a compiler. During compiling, the compiler can generate a contract module or contract file that includes the bytecode and other related data information for a smart contract. As described above, the bytecode is an intermediate code between a high-level language and a machine code, and needs to be parsed by a corresponding virtual machine before being executed.
As shown in
More specifically, in an implementation, the first contract in step 31 can be written in a Solidity language, and is compiled into a corresponding bytecode. Correspondingly, the method in
In an implementation, the first contract is written in a high-level language such as C/C++, and is compiled into a WASM bytecode. WASM, namely, WebAssembly, is an open standard developed by the W3C community group, and is a new coding method. WASM is a low-level assembly-like language with a compact binary format, and can run efficiently on a web with near-native performance. Therefore, WASM recently serves as a compilation target for a smart contract in a blockchain. In this case, a smart contract can be compiled into a WASM module or WASM file that includes a WASM bytecode.
After the bytecode corresponding to the first contract to be deployed is obtained, in step 33, the bytecode is processed into the executable instruction code, and the executable instruction codes are stored in the cache memory. Specifically, in the present step, the bytecode is loaded, parsed, and decoded, to convert the bytecode into the executable instruction code, and the executable instruction codes are stored in the cache memory.
In an implementation, the bytecode can be parsed after being loaded. Alternatively, in another implementation, the bytecode can be parsed while being loaded. The parsing operation can include identifying an operation code (opcode) in the bytecode and obtaining an analog function or a machine instruction for implementing an instruction operation represented by the operation code.
In a specific example, a bytecode corresponding to a Solidity smart contract includes 60 60 60 40 52 60 04 36 10 60 3f 57 60 00 35 7c . . . .
It can be seen that this is an array of hexadecimal digit codes, each array includes 2 bits, and occupies one byte, and each byte represents one operation code (opcode) or piece of operation data. Correspondingly, a bytecode file can be sequentially parsed by byte, and is, for example, converted into an assembly instruction operation.
Specifically, for the previous bytecode, the first byte “60” is first parsed, and an instruction corresponding to the value is queried from an assembly instruction set. The instruction corresponding to 60 is “push”. An input parameter is needed after a push instruction, and therefore the following byte “60” is a parameter of the push instruction. In this case, an assembly instruction “PUSH 60” (push 60 to a stack) is obtained. Then, the third byte “60” and the fourth byte are parsed, and an instruction “PUSH 40” is obtained. The next byte “52” is parsed, and an operation instruction “MSTORE” is obtained, where the operation instruction indicates that memory space is to be created to store data previously pushed to the stack. An assembly instruction is obtained through sequential parsing. Further, in an implementation, the assembly instruction can be converted into a machine instruction.
Memory space is allocated to the executable code obtained through parsing, and an instruction code of each instruction is stored.
In an example, the bytecode is encoded by using a variable-length coding method, and therefore instructions are variable-length instructions with different lengths. For example, a WASM bytecode is encoded by using the leb 128 variable-length coding method, to reduce a file size and better use storage space. Other bytecodes can be generated by using other coding methods.
Leb 128, namely, “Little-Endian Base 128”, is variable-length coding for any signed or unsigned integer. Therefore, the number of bytes occupied by an integer encoded by using leb 128 is changed based on a magnitude of the integer. According to the leb 128 coding method, in 8 bits (8 bits) of each byte, the less significant 7 bits are a valid data part, and the most significant bit is used to indicate whether the current byte is the last byte, where 1 indicates that the current byte is the last byte, and 0 indicates that the current byte is not the last byte, to be specific, a subsequent byte needs to be connected. In this case, different integers can be encoded by using different quantities of bytes.
Correspondingly, for the leb-encoded WASM bytecode, during data decoding, each byte is first restored to 8 bits, and whether a subsequent byte needs to be connected is determined by using the most significant bit, to jointly form target data. Therefore, variable-length instructions are obtained after the WASM bytecode is parsed and decoded. To store these instructions, the variable-length instruction can be converted into a memory-aligned fixed-length instruction. In this process, memory space allocated based on the fixed-length instruction needs to be adjusted. Correspondingly, a target address in a control transfer instruction, for example, a jump instruction, in the instructions obtained by parsing the bytecode needs to be modified.
Specifically, in the process of parsing the bytecode, specific memory space, for example, m, is first allocated to each instruction based on a predetermined default value. The control transfer instruction, for example, the jump instruction Jump or an invocation instruction Call, includes the target address. The target address is usually represented as an offset of a storage location relative to a storage location of a certain instruction (which is usually a start instruction). When a memory storage location of a variable-length instruction is adjusted, the target address in the control transfer instruction can be modified based on an adjusted memory storage location.
For example, the following instruction sequence is obtained after a bytecode is parsed:
Assume that the first instruction is a start instruction, and a memory location of the first instruction is marked as 0. The subsequent jump instruction JUMP 12 represents that an instruction to jump 12 memory units (namely, with a magnitude of m) relative to the starting memory location. Assume that before the jump instruction, two instructions are decoded as longer instructions. After the longer instructions are aligned with the cache memory, it can be determined that each of the longer instructions needs to be stored in two memory units, in other words, each of the longer instructions is converted into two memory-aligned fixed-length instructions. In this case, required memory expands. Then, the target address in the jump instruction can be correspondingly modified to 14.
As such, the bytecode is parsed into the executable instruction code, and the executable instruction codes are stored in the cache memory.
In addition, in step 35, the function index table is determined for the import and export functions in the bytecode, where the function index table is used to indicate the memory address of the instruction code corresponding to each of the import and export functions.
It should be understood that a smart contract usually includes several import and export functions. The import function is a function that is invoked by the smart contract and is in a function library provided by a system platform or a third party, and the export function is a function that is provided by the smart contract and is used as an interface for invocation by other users. In particular, when wanting to invoke the smart contract, another party can import parameters by invoking the export function in the contract.
As described above, in an implementation, a smart contract is compiled into a WASM module or a WASM file. The WASM file includes a plurality of sections that include an import section and an export section. The import section defines a function, a table, memory, a global variable, etc. imported by the module from another module, and the export section defines a function, a table, memory, a global variable, etc. exported from the module. Import and export functions in a bytecode corresponding to the smart contract can be determined based on content in these blocks.
In an implementation, the determined import and export functions are uniformly orchestrated, the memory addresses of the executable instruction codes obtained after the import and export functions are parsed are determined, and the function index table is determined based on the memory addresses.
In an implementation, the function index table can be a secondary index table, and includes a first index table and a second index table. The first index table includes a mapping relationship between a function name of each of the import and export functions and a function index number, and the second index table includes a mapping relationship between a function index number and a memory address.
In another implementation, a mapping relationship between a function name and a memory address can be directly established, to form the function index table.
It can be understood that in the previously described case of variable-length instructions, a memory address in the function index table is an adjusted memory address obtained after alignment is performed on the cache memory.
In step 37, the function index table is stored in the cache memory.
It can be seen from the previous process that in a phase of deploying a smart contract, a corresponding bytecode is preprocessed, where the preprocessing includes parsing and decoding, and import and export functions are orchestrated, to generate a data structure needed for running, namely, the previous function index table. As such, the process of executing the smart contract can be accelerated.
In step 51, a transaction request for invoking a first contract is received, where the transaction request includes a contract address and an invocation function of the first contract.
Before step 51, assume that the first contract has been created, and the first contract has been deployed by using the method shown in
Correspondingly, a virtual machine of any node that receives the transaction can determine the contract to be invoked by using the to field, and determine the function of the contract to be invoked by using the data field.
Then, in step 53, the virtual machine obtains, from a cache memory, an instruction code and a function index table that correspond to the first contract and are cached during a phase of deploying the first contract. It can be understood that corresponding to the procedure in
Therefore, in step 55, a memory address corresponding to the invocation function is determined based on the function index table.
In an implementation, the function index table includes a mapping relationship between a function name and a memory address. In this case, the memory address for storing the executable instruction codes corresponding to the function can be directly determined by using a function name.
In another implementation, the function index table is a secondary index table, and includes a first index table and a second index table. The first index table includes a mapping relationship between a function name of each of import and export functions and a function index number, and the second index table includes a mapping relationship between a function index number and a memory address. In this case, the first index table can be searched based on a function name of the invocation function, to determine an index number corresponding to the invocation function; and then the second index table is searched by using the index number, to determine the corresponding memory address.
Further, in step 57, the instruction code in the memory address is executed based on the determined memory address. The executable instruction codes obtained through parsing are stored in the memory address, and therefore execution can be directly performed, and no parsing is needed in the present step.
It can be seen from the previous process that in a deployment phase, a bytecode of a smart contract is preprocessed into a data structure needed for running, and therefore when the smart contract is invoked, execution can be directly performed, and no operations such as parsing, decoding, and target address modification are needed, thereby greatly improving execution efficiency. In addition, many smart contracts are repeatedly invoked and executed. A data structure generated during deployment can be reused by using the previous preprocessing solution. In other words, for each invoked smart contract, one parsing of the smart contract can facilitate multiple execution of the smart contract. As such, contract execution efficiency is further improved, and overall performance of a blockchain platform is also improved.
According to an implementation of another aspect, an apparatus for deploying a smart contract is provided. The apparatus is deployed in a virtual machine of any node in a blockchain network. The any node can be embodied as any device with computing and processing capabilities, any platform, or any device cluster. The virtual machine can be a virtual machine that adapts to a format of a smart contract, for example, a Solidity virtual machine or a WASM virtual machine.
According to an implementation, the request for deploying the first contract is to create a first transaction of the first contract, and correspondingly, the bytecode acquisition unit 61 is configured to extract the bytecode from a data field of the first transaction.
In a specific implementation, the bytecode is encoded by using a first coding protocol, and the first coding protocol is a variable-length coding protocol. In this case, the parsing unit 63 is configured to decode the bytecode by using a decoding protocol corresponding to the first coding protocol, and convert a variable-length instruction into a memory-aligned fixed-length instruction.
Further, in a specific example, the contract module is a WASM module, and the first coding protocol is a leb 128 coding protocol.
According to an implementation, in the case of a variable-length coding protocol, the parsing unit 63 is further configured to modify a target address in a control transfer instruction based on a memory-aligned instruction storage location.
According to an implementation, the function index table includes a first index table and a second index table, the first index table includes a mapping relationship between a function name of each of the import and export functions and a function index number, and the second index table includes a mapping relationship between a function index number and a memory address.
According to an implementation of another aspect, an apparatus for executing a smart contract is provided. The apparatus is deployed in a virtual machine of any node in a blockchain network. The any node can be embodied as any device with computing and processing capabilities, any platform, or any device cluster. The virtual machine can be a virtual machine that adapts to a format of a smart contract, for example, a Solidity virtual machine or a WASM virtual machine.
In an implementation, the function index table includes a first index table and a second index table, the first index table includes a mapping relationship between a function name of each of the import and export functions and a function index number, and the second index table includes a mapping relationship between a function index number and a memory address. In this case, the determining unit 75 is configured to search the first index table based on a function name of the invocation function, to determine an index number corresponding to the invocation function; and search the second index table by using the determined index number, to determine the corresponding memory address.
According to the apparatuses in the previous aspects, a corresponding bytecode can be preprocessed in a phase of deploying a smart contract, to generate a data structure needed for running. When the smart contract is invoked, execution can be directly performed based on the data structure, and no operations such as parsing, decoding, and target address modification are needed, thereby greatly improving execution efficiency.
According to an implementation of another aspect, a computer readable storage medium is provided. The computer readable storage medium stores a computer program, and when the computer program is executed in a computer, the computer is enabled to perform the method described in
According to an implementation of another aspect, a computing device is further provided, and includes a memory and a processor. The memory stores executable code, and when the processor executes the executable code, the method described with reference to FIG. 4 is implemented.
A person skilled in the art should be aware that in the previous one or more examples, functions described in the present disclosure can be implemented by hardware, software, firmware, or any combination thereof. When the present disclosure is implemented by software, the functions can be stored in a computer readable medium or transmitted as one or more instructions or code in a computer readable medium.
The objectives, technical solutions, and beneficial effects of the present disclosure are further described in detail in the previously described specific implementations. It should be understood that the previous descriptions are merely specific implementations of the present disclosure, and are not intended to limit the protection scope of the present disclosure. Any modification, equivalent replacement, or improvement made based on the technical solutions of the present disclosure shall fall within the protection scope of the present disclosure.
| Number | Date | Country | Kind |
|---|---|---|---|
| 201910818254.7 | Aug 2019 | CN | national |
This application is a continuation of and claims the benefit of priority of U.S. patent application Ser. No. 16/779,482, filed Jan. 31, 2020, which is a continuation of PCT Application No. PCT/CN2020/071571, filed on Jan. 11, 2020, which claims priority to Chinese Patent Application No. 201910818254.7, filed on Aug. 30, 2019, and each application is hereby incorporated by reference in their entirety.
| Number | Name | Date | Kind |
|---|---|---|---|
| 6697814 | Porter | Feb 2004 | B1 |
| 7676652 | Francis et al. | Mar 2010 | B2 |
| 8255922 | Fresko et al. | Aug 2012 | B1 |
| 8561042 | Choi et al. | Oct 2013 | B2 |
| 9830926 | Helwani | Nov 2017 | B2 |
| 10346310 | Elias et al. | Jul 2019 | B2 |
| 10476847 | Smith et al. | Nov 2019 | B1 |
| 10699269 | Blankstein | Jun 2020 | B1 |
| 10705866 | Wang | Jul 2020 | B2 |
| 10860350 | Sun | Dec 2020 | B2 |
| 10866823 | Sun | Dec 2020 | B2 |
| 20020062322 | Turetsky et al. | May 2002 | A1 |
| 20020104076 | Shaylor | Aug 2002 | A1 |
| 20030023958 | Patel et al. | Jan 2003 | A1 |
| 20030229769 | Montemayor | Dec 2003 | A1 |
| 20040015917 | Click et al. | Jan 2004 | A1 |
| 20040059890 | Francis et al. | Mar 2004 | A1 |
| 20040158678 | Chen | Aug 2004 | A1 |
| 20040210865 | Shimura | Oct 2004 | A1 |
| 20050149916 | Shpeisman et al. | Jul 2005 | A1 |
| 20060036809 | Rudd | Feb 2006 | A1 |
| 20060253847 | Romanovskiy | Nov 2006 | A1 |
| 20070118724 | Patel | May 2007 | A1 |
| 20090254759 | Michiels et al. | Oct 2009 | A1 |
| 20100057468 | Lin et al. | Mar 2010 | A1 |
| 20110191752 | Cleraux et al. | Aug 2011 | A1 |
| 20110276785 | Lee et al. | Nov 2011 | A1 |
| 20120233603 | Song et al. | Sep 2012 | A1 |
| 20120260102 | Zaks et al. | Oct 2012 | A1 |
| 20120331307 | Fernandez Gutierrez | Dec 2012 | A1 |
| 20120331308 | Fernandez Gutierrez | Dec 2012 | A1 |
| 20130232540 | Saidi et al. | Sep 2013 | A1 |
| 20140173577 | Mitchell et al. | Jun 2014 | A1 |
| 20170003967 | Lin et al. | Jan 2017 | A1 |
| 20170161196 | Henry et al. | Jun 2017 | A1 |
| 20170249252 | Elias et al. | Aug 2017 | A1 |
| 20170345011 | Salami et al. | Nov 2017 | A1 |
| 20180060048 | Gampe et al. | Mar 2018 | A1 |
| 20180088921 | Caprioli et al. | Mar 2018 | A1 |
| 20180089758 | Stradling | Mar 2018 | A1 |
| 20180091316 | Stradling et al. | Mar 2018 | A1 |
| 20180117446 | Tran et al. | May 2018 | A1 |
| 20180123779 | Zhang | May 2018 | A1 |
| 20180143746 | Stern et al. | May 2018 | A1 |
| 20180191503 | Alwar et al. | Jul 2018 | A1 |
| 20180300480 | Sawhney | Oct 2018 | A1 |
| 20180331835 | Jackson | Nov 2018 | A1 |
| 20190018947 | Li | Jan 2019 | A1 |
| 20190026716 | Anbukkarasu et al. | Jan 2019 | A1 |
| 20190102163 | Witherspoon | Apr 2019 | A1 |
| 20190130368 | Li et al. | May 2019 | A1 |
| 20190172026 | Vessenes et al. | Jun 2019 | A1 |
| 20190180276 | Lee et al. | Jun 2019 | A1 |
| 20190205894 | Gonzales, Jr. et al. | Jul 2019 | A1 |
| 20190207760 | Hennebert | Jul 2019 | A1 |
| 20190220836 | Caldwell | Jul 2019 | A1 |
| 20190273739 | Pemmaraju | Sep 2019 | A1 |
| 20190279201 | Xia et al. | Sep 2019 | A1 |
| 20190281065 | Xia et al. | Sep 2019 | A1 |
| 20190303926 | Yantis et al. | Oct 2019 | A1 |
| 20190324772 | Fan et al. | Oct 2019 | A1 |
| 20190334920 | Kelly | Oct 2019 | A1 |
| 20190354723 | Dassenno | Nov 2019 | A1 |
| 20190358515 | Tran | Nov 2019 | A1 |
| 20190361917 | Tran et al. | Nov 2019 | A1 |
| 20190373521 | Crawford | Dec 2019 | A1 |
| 20200019421 | Sun | Jan 2020 | A1 |
| 20200058023 | Travizano et al. | Feb 2020 | A1 |
| 20200092083 | Keshar | Mar 2020 | A1 |
| 20200101367 | Tran et al. | Apr 2020 | A1 |
| 20200104307 | Keshar | Apr 2020 | A1 |
| 20200110967 | Keshar | Apr 2020 | A1 |
| 20200117690 | Tran | Apr 2020 | A1 |
| 20200118068 | Turetsky | Apr 2020 | A1 |
| 20200142722 | Sun | May 2020 | A1 |
| 20200143471 | Jackson | May 2020 | A1 |
| 20200293346 | Wang | Sep 2020 | A1 |
| Number | Date | Country |
|---|---|---|
| 101425052 | May 2009 | CN |
| 102023843 | Apr 2011 | CN |
| 103530171 | Jan 2014 | CN |
| 104182267 | Dec 2014 | CN |
| 106020920 | Oct 2016 | CN |
| 106201893 | Dec 2016 | CN |
| 107133502 | Sep 2017 | CN |
| 107329888 | Nov 2017 | CN |
| 108021370 | May 2018 | CN |
| 108153518 | Jun 2018 | CN |
| 108337092 | Jul 2018 | CN |
| 108733988 | Nov 2018 | CN |
| 108765158 | Nov 2018 | CN |
| 108932406 | Dec 2018 | CN |
| 109034814 | Dec 2018 | CN |
| 109101237 | Dec 2018 | CN |
| 109214179 | Jan 2019 | CN |
| 109542455 | Mar 2019 | CN |
| 109710384 | May 2019 | CN |
| 109710385 | May 2019 | CN |
| 109710680 | May 2019 | CN |
| 109711119 | May 2019 | CN |
| 109840429 | Jun 2019 | CN |
| 109901841 | Jun 2019 | CN |
| 109933410 | Jun 2019 | CN |
| 109949156 | Jun 2019 | CN |
| 109976871 | Jul 2019 | CN |
| 110032838 | Jul 2019 | CN |
| 110096338 | Aug 2019 | CN |
| 110162306 | Aug 2019 | CN |
| 110175454 | Aug 2019 | CN |
| 110675256 | Jan 2020 | CN |
| Entry |
|---|
| BlockChain Technology Beyon BitCoin, Pantas et al., (Year: 2015). |
| Deploying smart contract with truffle, Michael Zalecki (Year: 2018). |
| Smart Contract Defense through Bytecode Rewriting, Ayoade et al., IEEE (Year: 2019). |
| Recycling Smart Contracts: Compression of the Ethereum Blockchain, Pontiveros et al., IEEE (Year: 2018). |
| Interpreted Execution of Business Process Models on Blockchain, Pintado et al., IEEE (Year: 2019). |
| Crosby et al., “BlockChain Technology: Beyond Bitcoin,” Sutardja Center for Entrepreneurship & Technology Technical Report, Oct. 16, 2015, 35 pages. |
| Hu et al., “Research on Smart Contract Optimization Method on Blockchain,” IT Professional, Sep. 2019, 21(5):33-38. |
| Michalzalecki.com [online], “Deployig smart contracts with Truffle,” Mar. 2018, retrieved on May 13, 2020, retrieved from URL<https://michalzalecki.conn/deploying-smart-contracts-with-truffle/>, 7 pages. |
| Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash System,” www.bitcoin.org, 2005, 9 pages. |
| PCT International Search Report and Written Opinion in International Application No. PCT/CN2020/071571, dated Jun. 2, 2020, 10 pages. |
| Number | Date | Country | |
|---|---|---|---|
| 20200364149 A1 | Nov 2020 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 16779482 | Jan 2020 | US |
| Child | 16944122 | US | |
| Parent | PCT/CN2020/071571 | Jan 2020 | US |
| Child | 16779482 | US |
