CN116010100A

CN116010100A - Contract calling method, device, equipment and storage medium in block chain system

Info

Publication number: CN116010100A
Application number: CN202310089110.9A
Authority: CN
Inventors: 黄方蕾; 邱炜伟; 卢益铭; 张珂杰; 尚璇
Original assignee: Hangzhou Qulian Technology Co Ltd
Current assignee: Hangzhou Qulian Technology Co Ltd
Priority date: 2023-01-16
Filing date: 2023-01-16
Publication date: 2023-04-25

Abstract

The application is applicable to the technical field of blockchain, and provides a contract calling method, a contract calling device, contract calling equipment and a contract calling storage medium in a blockchain system, wherein the contract calling method comprises the following steps: receiving a first intelligent contract call request; creating a first execution context space corresponding to the first smart contract call request and determining a contract code space corresponding to the first smart contract call request; the contract code space is used for storing a runtime module corresponding to the intelligent contract; determining a target runtime module required by the first intelligent contract call request called contract based on the contract code space; the target runtime module is executed based on the first execution context space. The scheme can support parallel execution of contract call, avoid the execution overhead of repeatedly processing the same byte code, and occupy less memory.

Description

Contract calling method, device, equipment and storage medium in block chain system

Technical Field

The application belongs to the technical field of blockchain, and particularly relates to a contract calling method, device and equipment in a blockchain system and a storage medium.

Background

The existing blockchain system executes intelligent contracts in parallel by utilizing a transaction parallel technology, so that the overall execution performance of the blockchain is improved.

In one implementation, multiple smart contracts are executed in parallel by creating multiple smart contract execution engine instances. Some smart contract execution engines themselves typically contain some built-in library code that is stored in the smart contract engine after being parsed and linked, e.g., the Java smart contract execution engine provides a built-in JDK code library. The memory space between different intelligent contract execution engine instances is completely isolated, so that the memory access results of the intelligent contract execution engine instances are not affected by other threads when the intelligent contracts are executed in parallel. In this mode, each execution engine instance stores the built-in library code after the analysis of the link is completed, and when the execution engine instance calls the next contract, only the link contract code needs to be analyzed again, but a large amount of memory is occupied, so that the multiple execution engine instances mean that the built-in library code is stored redundantly, and the storage cost is high.

In another implementation, by allowing multiple threads to execute smart contracts in one smart contract execution engine, such smart contracts require parsing and linking prior to execution.

In this case, although it is not necessary to create a plurality of execution engine instances, each time a thread in one smart contract execution engine needs to re-parse and link the built-in library code and the contract code related to the contract before executing the smart contract, and even if the same contract code is used, a memory area is required to store the byte code parsed and linked data in different threads, and thus additional memory overhead exists.

Disclosure of Invention

The embodiment of the application provides a contract calling method, device, equipment and storage medium in a blockchain system, which are used for solving the problems of code storage redundancy and extra memory overhead in the prior art.

A first aspect of an embodiment of the present application provides a contract invoking method in a blockchain system, including:

receiving a first intelligent contract call request;

creating a first execution context space corresponding to the first smart contract call request and determining a contract code space corresponding to the first smart contract call request; the contract code space is used for storing a runtime module corresponding to the intelligent contract;

determining a target runtime module required by the first intelligent contract call request called contract based on the contract code space;

The target runtime module is executed based on the first execution context space.

A second aspect of an embodiment of the present application provides a contract invoking apparatus in a blockchain system, including:

the receiving module is used for receiving a first intelligent contract calling request;

an acquisition module, configured to create a first execution context space corresponding to the first smart contract call request and determine a contract code space corresponding to the first smart contract call request; the contract code space is used for storing a runtime module corresponding to the intelligent contract;

an information determining module, configured to determine, based on the contract code space, a target runtime module required by the contract invoked by the first intelligent contract invocation request;

and the execution module is used for executing the target runtime module based on the first execution context space.

A third aspect of the embodiments of the present application provides a computer device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, the processor implementing the steps of the method according to the first aspect when executing the computer program.

A fourth aspect of the embodiments of the present application provides a computer-readable storage medium storing a computer program which, when executed by a processor, implements the steps of the method according to the first aspect.

A fifth aspect of the present application provides a computer program product for, when run on a computer device, causing the computer device to perform the steps of the method of the first aspect described above.

According to the embodiment of the application, the execution context space corresponding to the intelligent contract calling request is created, the contract code space corresponding to the intelligent contract calling request is determined, the target runtime module required by the contract called by the intelligent contract calling request is determined based on the contract code space, the target runtime module is executed based on the execution context space and the target runtime module, the intelligent contract is allowed to be executed in a multithreading mode in one intelligent contract execution engine instance, transaction parallel execution can be supported only by one intelligent contract execution engine instance, the execution overhead of repeatedly processing the same byte codes is avoided, and the occupied memory is small.

Drawings

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

FIG. 1 is a flow chart of a contract invoking method in a blockchain system provided in an embodiment of the present application;

FIG. 2 is a schematic diagram of a storage space structure according to an embodiment of the present disclosure;

FIG. 3 is a block diagram of a contract invoking mechanism in a blockchain system provided in an embodiment of the present application;

fig. 4 is a block diagram of a computer device according to an embodiment of the present application.

Detailed Description

In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular system configurations, techniques, etc. in order to provide a thorough understanding of the embodiments of the present application. It will be apparent, however, to one skilled in the art that the present application may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present application with unnecessary detail.

It should be understood that the terms "comprises" and/or "comprising," when used in this specification and the appended claims, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

It is also to be understood that the terminology used in the description of the present application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in this specification and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

It should be further understood that the term "and/or" as used in this specification and the appended claims refers to any and all possible combinations of one or more of the associated listed items, and includes such combinations.

As used in this specification and the appended claims, the term "if" may be interpreted as "when..once" or "in response to a determination" or "in response to detection" depending on the context. Similarly, the phrase "if a determination" or "if a [ described condition or event ] is detected" may be interpreted in the context of meaning "upon determination" or "in response to determination" or "upon detection of a [ described condition or event ]" or "in response to detection of a [ described condition or event ]".

In particular implementations, the computer devices described in embodiments of the present application include, but are not limited to, other portable devices such as mobile phones, laptop computers, or tablet computers having a touch-sensitive surface (e.g., a touch screen display and/or a touch pad). It should also be appreciated that in some embodiments, the device is not a portable communication device, but a desktop computer having a touch-sensitive surface (e.g., a touch screen display and/or a touch pad).

In the following discussion, a computer device including a display and a touch-sensitive surface is described. However, it should be understood that a computer device may include one or more other physical user interface devices such as a physical keyboard, mouse, and/or joystick.

The computer device supports various applications, such as one or more of the following: drawing applications, presentation applications, word processing applications, website creation applications, disk burning applications, spreadsheet applications, gaming applications, telephony applications, video conferencing applications, email applications, instant messaging applications, workout support applications, photo management applications, digital camera applications, digital video camera applications, web browsing applications, digital music player applications, and/or digital video player applications.

Various applications that may be executed on the computer device may use at least one common physical user interface device such as a touch sensitive surface. One or more functions of the touch-sensitive surface and corresponding information displayed on the computer device may be adjusted and/or changed between applications and/or within corresponding applications. In this way, a common physical architecture (e.g., touch-sensitive surface) of the computer device may support various applications with user interfaces that are intuitive and transparent to the user.

It should be understood that the sequence number of each step in this embodiment does not mean the sequence of execution, and the execution sequence of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiment of the present application.

In order to illustrate the technical solutions described in the present application, the following description is made by specific examples.

Referring to fig. 1, fig. 1 is a flowchart of a contract invoking method in a blockchain system provided in an embodiment of the present application. As shown in fig. 1, a contract invoking method in a blockchain system, the method comprising the steps of:

step 101, receiving a first intelligent contract calling request;

Step 102, creating a first execution context space corresponding to the first smart contract call request and determining a contract code space corresponding to the first smart contract call request.

The contract code space is used for storing a runtime module corresponding to the intelligent contract. The first execution context space comprises a dynamic code space and a static field space, wherein the dynamic code space is used for storing a dynamic contract called by the first intelligent contract calling request, and the static field space is used for storing a contract code static field parameter corresponding to the contract called by the first intelligent contract calling request.

In one example, execution context spaces of different smart contract invocation requests exist in parallel.

In this case, step 102 creates a first execution context space corresponding to the first smart contract call request and determines a contract code space corresponding to the first smart contract call request, including:

and if the second execution context space corresponding to the second intelligent contract calling request exists in the memory, opening up other spaces from the memory as the first execution context space corresponding to the first intelligent contract calling.

The first intelligent contract call request and the first execution context space correspond to a first thread, the second intelligent contract call request and the second execution context space correspond to a second thread, and the first thread and the second thread execute in parallel.

In one example, the first thread and the second thread correspond to the same smart contract execution engine.

In the whole architecture of the embodiment of the application, after the intelligent contract is well compiled, the intelligent contract can be run on the virtual machine after being compiled by a compiler, the compiling result of the intelligent contract is called as byte codes, and the byte codes are byte arrays of a string of hexadecimal digital codes. Byte code is parsed in bytes, each byte representing an instruction or an operation data.

The bytecode of the smart contract code needs to be converted into a runtime module.

Byte codes are a section of binary byte stream encoded according to a specific rule, and cannot be directly used for execution, and certain processing is required, so that the byte codes are required to be converted into a runtime module. The process of converting byte codes into the runtime modules specifically comprises the following steps:

reading the corresponding byte codes according to the module name; initializing byte codes, wherein the initialization process comprises loading, linking, analyzing and the like, and obtaining an uninitialized runtime module after completion; the module is initialized, the initialization method of the module is executed, default values are given to static fields in the module, and the completed runtime module can be used for executing.

In an exemplary storage space architecture of the present application, as shown in fig. 2, for an intelligent contract execution engine, the memory model can be represented as three levels:

built-in library code space: and the method is responsible for the operations of storing, analyzing, linking and the like of the byte codes of the built-in library, and all threads share the built-in library code space. The built-in library code only needs to be initialized once by a certain thread when being accessed for the first time, and then the corresponding runtime module can be directly accessed when other threads are accessed.

Contract code space: and the system is responsible for operations such as storing, analyzing, linking and the like of the contract byte codes, the contract code space is cached in a contract cache space, and threads calling the same contract byte codes share the same contract code space.

Execution context space: the execution context space comprises a dynamic code space and a static field space, and a thread has an independent execution context space.

Wherein the dynamic code space: and the method is responsible for dynamically calling the operations of storage, analysis, linkage and the like of the introduced byte codes in the contract executing process. Static field space: and the static field of the contract can store one data in the context space corresponding to each thread to ensure the data isolation of the static field among different threads.

The content in the built-in code space and the contract code space can be shared by different threads, and the overhead of repeatedly initializing the runtime module can be eliminated.

Step 103, determining a target runtime module required by the contract called by the first intelligent contract call request based on the contract code space.

The process requires execution of contract call logic based on the smart contract call request.

In an alternative embodiment, different contract code spaces point to the same built-in library code space, and the built-in library code space is used for storing runtime modules corresponding to set intelligent contracts.

Correspondingly, step 103 determines, based on the contract code space, a target runtime module required by the contract invoked by the first smart contract invocation request, including:

extracting a target runtime module required by a contract called by the first intelligent contract calling request from the built-in library code space based on the contract code space; or,

extracting a target runtime module required by the contract called by the first intelligent contract calling request from the contract code space; or,

extracting a target runtime module required by the contract called by the first intelligent contract calling request from a dynamic code space based on the contract code space; the dynamic code space is used for storing a dynamic contract called by the first intelligent contract call request, and the dynamic code space is contained in the first execution context space.

The above-mentioned process needs to be implemented based on a memory space architecture, specifically, a target runtime module needed by a contract called by an intelligent contract call request needs to be extracted from a built-in library code space, a contract code space and a dynamic code space in a prioritized manner.

Specifically, in one example, based on the contract code space, a target runtime module required by the contract called by the first smart contract call request is extracted from the built-in library code space, including:

judging whether a runtime module corresponding to a target module name is loaded in a built-in library code space pointed by the contract code space;

if not, judging whether byte codes corresponding to the target runtime module exist in the built-in library code space;

if so, generating an uninitialized runtime module based on the byte code;

and initializing the uninitialized runtime module to obtain the target runtime module.

And if the fact that the runtime module corresponding to the target module name is loaded in the built-in library code space pointed by the contract code space is judged, determining the runtime module corresponding to the target module name as the target runtime module.

The processing procedure corresponds to an access mechanism of the built-in library code space.

Wherein, the built-in library is explained first. The built-in library is a basic code library provided by the intelligent contract execution engine, and comprises a plurality of general code tools, which are usually provided by an execution engine developer and have controllability. The contract developer can use codes in the built-in library when writing intelligent contracts, so that development efficiency is improved.

In one embodiment of the present application, the built-in library is required to meet the following requirements:

static fields of the built-in library cannot be modified by the intelligent contract; the type of static field value of the built-in library must be the type provided by the built-in library; the code executed by the built-in library is deterministic and cannot initiate dynamic calls.

The built-in library meeting the above requirements can ensure that the method in the built-in library is called by any intelligent contract at any time, and the execution flow and the result are necessarily consistent as long as the input data are the same. Therefore, the built-in library code only needs to be initialized once by a certain thread to initialize the byte code and the runtime module in the built-in library code space when being accessed for the first time, and then other threads can directly access the corresponding runtime module when being accessed.

Optionally, in the parallel execution process of multiple threads corresponding to different intelligent contract calling requests and execution context spaces, if not, judging whether the built-in library code space has the byte code corresponding to the target run-time module, and introducing a module initialization lock function of the built-in library code space in the execution process of the byte code corresponding to the target run-time module, so as to ensure that different threads perform ordered calling execution when sharing calling on the same built-in library code space in the parallel execution process.

The process specifically comprises the following steps:

if the fact that the runtime module corresponding to the target module name is not loaded in the built-in library code space pointed by the contract code space is judged, a first module initialization lock of the built-in library code space is applied;

if the first module initialization lock is occupied by a thread corresponding to other intelligent contract calling requests, acquiring the first module initialization lock under the condition that the first module initialization lock is released;

based on the first module initialization lock, judging whether a runtime module corresponding to the target module name exists in the built-in library code space;

if not, judging whether the byte code corresponding to the target runtime module exists in the built-in library code space.

Or if the fact that the runtime module corresponding to the target module name is not loaded in the built-in library code space pointed by the contract code space is judged, a first module initialization lock of the built-in library code space is applied;

if the first module initialization lock is not occupied by threads corresponding to other intelligent contract calling requests, judging whether byte codes corresponding to the target runtime module exist in the built-in library code space or not based on the applied first module initialization lock.

And continuing the initialization processing process of the run-time module in the built-in library code space, realizing the combination of the module initialization phase locking with the built-in library code space, and ensuring the module sharing of the built-in library code space and the orderly processing of the module initialization when the multithreading is executed in parallel.

Correspondingly, the access flow of the built-in library code space is specifically as follows:

when the intelligent contract is executed and the built-in library code is required to be accessed, a runtime module of the built-in library is required to be obtained from a built-in library code space according to the following flow:

1. the module name that needs to be accessed is entered.

2. Checking whether the runtime module corresponding to the module name in the built-in library code space is loaded, if so, proceeding to step 8, and if not, proceeding to step 3.

3. The current thread applies for a lock initialized by a built-in library module in the built-in library code space.

4. The module name is checked again to see if the corresponding runtime module is loaded, and it is necessary to check again, considering that the current thread has already completed the initialization of the module during the lock application period for other threads holding the lock. Step 8 is entered if it has been loaded and step 5 is entered if it has not been loaded.

5. And judging whether the byte code of the target module exists, if not, directly returning an error, and if so, entering step 6.

6. And reading the byte code of the target module and carrying out byte code initialization work to obtain an uninitialized module.

7. Executing the initialization method of the module, obtaining the initialized module and storing the initialized module.

8. And returning to the target module.

In one example, the extracting, from the contract code space, a target runtime module required by the contract invoked by the first smart contract invocation request includes:

if not, judging whether a runtime module corresponding to the target module name is loaded in the contract code space;

And if so, determining the runtime module corresponding to the target module name in the contract code space as the target runtime module.

Further, after determining whether to load the runtime module corresponding to the target module name in the contract code space, the method further includes:

if not, judging whether byte codes corresponding to the target runtime module exist in the contract code space;

if so, generating an uninitialized runtime module based on the byte code;

The above processing corresponds to a contract code space access mechanism.

Wherein, the contract code is described first. The contract code is code written by a contract developer according to a business scenario, wherein the code to a part of the built-in library is used. In the blockchain, a contract developer needs to deploy a contract to the blockchain in a transaction mode, and a contract code after successful deployment is stored in a state database. In addition to this, the contract code may also involve dynamic calls, such as calling specific call code in-coming or introducing code of other contracts by calling across contracts.

Wherein the status database is a module in the blockchain system that stores account data as well as contract data.

When the same contract is called by multithreading, the contract code space has the following characteristics:

the runtime module corresponding to the stored contract code can be shared by a plurality of threads; the static variables in the contract code are private threads, and each thread stores one static variable in the context space of the thread; the code and the runtime module introduced by dynamic call are private threads and cannot be accessed by other threads; the different contract code spaces are isolated from each other and cannot be accessed to each other.

The contract code space meeting the requirements can ensure that intelligent contract execution among threads is isolated from each other and not interfered with each other while sharing the runtime module of the contract code.

In one storage space architecture, a plurality of contract code spaces can be provided, and the plurality of contract code spaces are cached in the contract cache space.

The contract cache space is used for caching the contract code space of part of contracts, and the cached contract code space can be accessed by one or more threads, so that the overhead of the initial combination contract runtime module of other threads is reduced.

Considering that there are a large number of contracts that may be invoked in a blockchain system, the contract cache space cannot permanently hold the contract code space, and some of the contract code space may be obsolete due to the cache policy. When the contract code space of the target contract does not exist in the contract cache space, the contract code space needs to be newly built in the contract cache space, and the thread using the contract code space is used for byte code initialization and runtime module initialization. When other threads access later, the loaded runtime module can be accessed directly as long as the contract code space exists in the cache.

Optionally, in the executing process of the byte code corresponding to the target runtime module in the contract code space, if not loaded, the module introducing the contract code space initializes a lock function to ensure that different threads perform ordered calling execution when sharing calling on the same contract code space in the parallel executing process.

The process specifically comprises the following steps:

If the runtime module corresponding to the target module name is not loaded in the contract code space, a second module initialization lock of the contract code space is applied;

if the second module initialization lock is occupied by a thread corresponding to other intelligent contract calling requests, acquiring the second module initialization lock under the condition that the second module initialization lock is released;

based on the second module initialization lock, judging whether a runtime module corresponding to the target module name exists in the contract code space;

if not, judging whether the byte code corresponding to the target runtime module exists in the contract code space.

Or if the runtime module corresponding to the target module name is not loaded in the contract code space, applying for a second module initialization lock of the contract code space;

if the second module initialization lock is not occupied by threads corresponding to other intelligent contract calling requests, judging whether byte codes corresponding to the target runtime module exist in the contract code space or not based on the applied second module initialization lock.

And continuing the initialization processing process of the runtime module in the contract code space, realizing the combination of the module initialization phase locking with the contract code space, and ensuring the module sharing and the orderly processing of the module initialization of the contract code space when the multithreading is executed in parallel.

On this basis, the access flow of the contract code space is as follows:

when the intelligent contract executing process needs to access the contract code space, a runtime module in the contract code space needs to be acquired according to the following flow:

1. the module name that needs to be accessed is entered.

2. An attempt is made to obtain a runtime module corresponding to the module name from the built-in library code space. If the runtime module is in the built-in library code space and successfully acquired, step 8 is entered. If it does not belong to the built-in library code space, step 3 is entered.

3. It is checked whether the corresponding runtime module has been loaded in the contract code space and if so step 8 is entered. If not, go to step 4.

4. The current thread applies for a contract code space initialization lock.

5. Again checking if the corresponding contract runtime module is loaded, and considering that the current thread has had other threads holding the contract code space initialization lock already completed the initialization work for the module during the lock application, a re-check is required. Step 8 is entered if it has already been loaded.

6. And judging whether the byte code of the target module exists in the contract code space, if not, directly returning to an error, and if so, entering step 7.

7. And reading the byte code of the target module, initializing the byte code, obtaining an uninitialized module, and storing the uninitialized module.

8. And returning to the target module. The modules stored in the contract code space are all uninitialized modules which do not contain static field information. Specifically, in one example, the extracting, based on the contract code space, a target runtime module required by the contract called by the first smart contract call request from a dynamic code space includes:

if not, judging whether a runtime module corresponding to the target module name is loaded in the dynamic code space;

and if so, determining the runtime module corresponding to the target module name in the dynamic code space as the target runtime module.

Wherein optionally, after determining whether to load a runtime module corresponding to the target module name in the dynamic code space, the method further comprises:

if not, judging whether the byte code corresponding to the target runtime module exists in the dynamic code space;

if so, generating an uninitialized runtime module based on the byte code;

The processing procedure corresponds to a dynamic code space access mechanism. Wherein, the dynamic code is explained first. Dynamic code, unlike built-in library code or contract code, can only determine the actual bytecode during execution. In one example, the smart contract execution engine provides code dynamic invocation mechanisms, such as implementing cross-contract invocations in a dynamically loaded mechanism, or initiating dynamic invocations in the form of transaction-in code scripts, or the like. The dynamic code has the following characteristics:

the life cycle is short, the dynamic code is loaded in the process of one contract call, and the dynamic code is invalid when the call is ended. Threads are private and cannot be shared among threads. The dynamically invoked bytecode cannot be determined before execution.

In the embodiment of the application, all dynamic codes involved in the contract calling process are saved in the dynamic code space of the context space, and a thread can only access a module of the dynamic code space.

Dynamic code registration is required during a specific application.

The dynamic code space is created prior to contract execution, at which time the dynamic code space does not have bytecodes. In the execution process of the intelligent contract, dynamic code registration is needed when dynamic call is initiated, and the flow is as follows:

and inputting the module name required to be dynamically called and the corresponding byte code.

2. And judging whether the byte code of the corresponding module exists. If the bytecode of the corresponding module does not exist, step 3 is entered. If the bytecode of the corresponding module exists, step 4 is entered.

3. And storing the byte codes of the corresponding modules in a dynamic code space, and registering successfully.

4. The byte codes of the homonymous modules already existing in the dynamic code space are read.

5. It is determined whether the inputted bytecode is identical to an existing bytecode. If the two bytecodes are identical, indicating that the registered module already exists, returning that the registration is successful. If the bytecodes are not consistent, a registration failure is returned.

Correspondingly, the access flow of the dynamic code space is specifically as follows:

when the intelligent contract execution process needs to access the dynamic code space, a runtime module of the dynamic code needs to be acquired according to the following flow:

1. the module name that needs to be accessed is entered.

2. An attempt is made to acquire a module from the built-in library code space. If the module is in a built-in library and successfully acquired, step 8 is entered. If it does not belong to the built-in library code space, step 3 is entered.

3. Attempting to acquire a module from the contract code space, if the module is located in the contract code space and successfully acquired, then step 8 is entered. If it does not belong to the contract code space, step 4 is entered.

4. It is checked whether the corresponding module has been loaded in the dynamic code space and if so step 8 is entered. If not, go to step 5.

5. And reading the byte code of the target module. Judging whether the byte code exists or not, and if so, entering step 6. If the bytecode does not exist, the dynamic code is not registered, and an error is returned.

6. And performing byte code initialization work on the byte code of the target module to obtain an uninitialized module, and storing the uninitialized module.

7. And initializing the module to obtain an initialized module.

8. And returning to the target module.

Further, in one example, the first execution context space includes a static field space for storing contract code static field parameters corresponding to a contract invoked by the first smart contract invocation request.

Correspondingly, as mentioned in the foregoing embodiments, the initializing process is performed on the uninitialized runtime module to obtain the target runtime module, which includes:

reading the static field parameters of the contract codes from the static field space;

and carrying out parameter initialization processing on the uninitialized runtime module based on the static field parameters of the contract code to obtain the target runtime module.

The method and the device realize initializing processing of the uninitialized runtime module based on the static field parameters of the contract code recorded in the context execution space corresponding to the intelligent contract calling thread.

This procedure corresponds to the access mechanism of the static field.

In the access flow of the contract code space, the end result is an uninitialized module that does not contain static field information. In the scenario of intelligent contract parallel call, different threads are not allowed to share the value of accessing the static field, so the modules which do not contain the static field are saved in the contract code space. And the static field of the runtime module corresponding to the contract code is saved into the static field space of the execution context space of each thread.

Correspondingly, the static field access flow is as follows:

in one example, access to the static fields is affected by the type of contract, which has different storage locations for the static fields. The static field access flow is as follows:

1. static field information of the smart contract to be accessed is entered.

2. And judging whether the intelligent contract belongs to a contract library. If the contract library does not belong, the static field existing in the memory is directly accessed, and the process proceeds to step 7. If it belongs to the contract library, step 3 is entered.

3. The static field space corresponding to the contract is accessed from the context space.

4. It is determined whether the contract library module has been initialized. If the module initialization has been completed, step 6 is entered. If the initialization is not completed, step 5 is entered.

5. And (3) acquiring a module initialization method, opening up a memory space for storing the static field of the module in the static field space, and executing the module initialization method to obtain an initialized module.

6. The module static field is accessed in a static field space.

7. And returning the access result of the static field.

Step 104, executing the target runtime module based on the first execution context space.

The specific application flow is described by combining the steps:

in the application, the smart contract execution engine receives a first smart contract call request, where the request includes a called contract address, a calling method, and input parameters. The smart contract execution engine creates a first execution context space for the received first smart contract call request, the first execution context space including a dynamic code space and a static field storage space. The intelligent contract execution engine acquires the CodeHash of the contract from the state database according to the contract address, and acquires the contract code space corresponding to the current CodeHash from the contract cache space according to the CodeHash. The CodeHash is an attribute of contract account data, and is obtained by carrying out hash calculation on byte codes based on contracts, wherein the CodeHash of the same contract byte codes is consistent, and the CodeHash of different contract byte codes is inconsistent.

Next, the smart contract execution engine executes logic of the contract call.

When the intelligent contract execution engine needs to access codes in the built-in library code space, the needed runtime module is obtained according to the access mechanism of the built-in library code space. When the smart contract execution engine needs to access code in the contract code space, the required runtime modules are obtained according to the access mechanism of the contract code space. When the intelligent contract execution engine initiates dynamic call, the required runtime module is obtained according to the access mechanism of the dynamic code space.

An example is described below in connection with a specific application scenario.

Suppose that there is currently a parallel invocation of contract 1 by transaction 1 and transaction 2. Transaction 1 involves code A1 in the built-in library, contract code B1, throughout execution. Transaction 2 involves built-in library code A1, A2, contract code B1 throughout execution. Wherein code B1 is located in contract code space 1. Transaction n is referred to below as the thread that performs transaction n. The execution flow is as follows:

1. transaction 1 accesses contract code B1 and, if the B1 module is found not loaded, acquires the lock for contract code space 1.

2. Transaction 2 accesses contract code B1, finds that the B1 module is not loaded, attempts to acquire the lock of contract code space 1, finds that the lock of contract code space 1 has been acquired by transaction 1, and thus transaction 2 blocks.

3. Transaction 1 completes the byte code initialization of contract code B1, resulting in uninitialized execution time module B1 and releasing the lock of contract code space 1.

4. The transaction 1 performs the module initialization work of the module B1, and stores the static field into the static field space of the first execution context space of the transaction 1, so as to obtain the initialized execution time module B1.

5. Transaction 2 acquires the lock of contract code space 1, discovers that the B1 module has been loaded, directly acquires the uninitialized module B1, and releases the lock of contract code space 1.

6. The transaction 2 performs the module initialization work of the module B1, and stores the static field into the static field space of the first execution context space of the transaction 2 itself, to obtain the initialized module B1.

7. Transaction 2 accesses the built-in library code A2 and finds that the A2 module is not loaded, obtaining a lock to the built-in library code space.

8. Transaction 1 accesses the built-in library code A1 and attempts to acquire the lock of the built-in library code space if the A1 module is found not loaded, and discovers that the lock of the built-in library code space has been acquired by transaction 2, so transaction 1 is blocked.

9. Transaction 2 performs the byte code initialization work and the module initialization work of the built-in library A2, and discovers that the module A2 depends on the module A1. Transaction 2 further performs a byte code initialization operation and a module initialization operation for the built-in library code A1. After transaction 2 completes the byte code initialization work of A1 and A2 and the module initialization work, the held built-in library lock is released.

10. Transaction 1 acquires the lock of the built-in library code space, discovers that the module A1 has completed initialization, acquires the initialized built-in library module A1, and releases the held built-in library lock.

An example is described below in connection with another specific application scenario.

Suppose that there is currently a parallel invocation contract for transaction 3, transaction 4, and transaction 5. Wherein both transaction 3 and transaction 4 call contract 2, i.e., access contract code space 2, and transaction 5 calls contract 3, i.e., access contract code space 3.

Transaction 3 involves contract code B2, dynamic code C1, throughout execution. Transaction 4 involves contract code B2, dynamic code C2, throughout execution. Transaction 4 involves contract code B3, dynamic code C1, throughout execution. Wherein code B2 is located in contract code space 2 and wherein code B3 is located in contract code space 3. Transaction n is referred to below as the thread that performs transaction n. The execution flow is as follows:

1. transaction 3 accesses contract code B2 and obtains the lock of contract code space 2 if the module corresponding to B2 is not loaded.

2. Transaction 4 accesses contract code B2 and attempts to acquire the lock of contract code space 2 if the module corresponding to B2 is found not loaded, and finds that the lock of contract code space 2 is held by transaction 3 and transaction 4 is blocked.

3. Transaction 5 accesses contract code B3 and obtains the lock of contract code space 3 if the module corresponding to B3 is not loaded. (because B2 and B3 belong to different contract code spaces, are isolated from each other, may not be loaded).

4. Transaction 3 completes the byte code initialization of module B2, resulting in uninitialized module B2 and releasing the lock of contract code space 2.

5. Transaction 5 completes the byte code initialization work for module B3, resulting in uninitialized module B3 and releasing the lock of contract code space 3.

6. Transaction 4 acquires the lock of contract code space 2, discovers that module B2 has been loaded, obtains uninitialized module B2, and releases the lock of contract code space 2.

7. Transaction 3 completes the module initialization work for module B2 in its own context space.

8. Transaction 4 completes the module initialization work for module B2 in its own context space.

9. Transaction 5 completes the module initialization work for module B3 in its own context space.

10. Transaction 3 registers the bytecode of dynamic code C1 in its own dynamic code space.

11. Transaction 4 registers the bytecode of dynamic code C2 in its own dynamic code space.

12. Transaction 5 registers the bytecode of dynamic code C1 in its own dynamic code space.

13. Transaction 3 initiates dynamic call to the C1 module, checks the dynamic code space of the module, and finds that C1 is not loaded, then the byte code initialization work and the module initialization work of C1 are performed, and an initialized module C1 is obtained (the process does not need locking).

14. Transaction 4 initiates dynamic call to the C2 module, checks the dynamic code space of the module, and finds that C2 is not loaded, then the byte code initialization work and the module initialization work of C2 are performed, and an initialized module C2 is obtained (the process does not need locking).

15. Transaction 5 initiates dynamic call to the C1 module, checks the dynamic code space of the module, and finds that C1 is not loaded, then the byte code initialization work and the module initialization work of C1 are performed, and an initialized module C1 is obtained (the process does not need locking).

The embodiments of the present application refer to the concept that the multithreading parallelism of the intelligent contract is different from the multithreading parallelism of the programming language, and the multithreading parallelism of the intelligent contract is isolated on the memory, that is, there is no shared variable in the contract that can be accessed and modified by multiple threads in parallel. While multithreaded parallelism in a programming language is a mechanism that allows certain variables in code logic to be modified by multiple threads of parallel access.

Further, after executing the target runtime module based on the first execution context space, further comprising:

and after the target runtime module is executed, clearing all data in the first execution context space and deleting the runtime module in the memory.

Wherein, deleting the run-time module in the memory may be deleting all or deleting part. In an alternative method, the runtime module corresponding to the built-in library code can be permanently stored, and the runtime module corresponding to the contract code is cleared and managed according to a specific caching strategy.

In the process, after the intelligent contract execution engine finishes the contract call flow, all data in the first execution context space and the runtime module need to be emptied, so that the built-in library codes and the runtime modules corresponding to the contract codes are managed according to the maintenance strategy of the execution engine.

The above embodiments of the present application provide a method for supporting multithreading parallelism of smart contracts, which allows smart contracts to be executed in a multithreading manner in one smart contract execution engine instance, and only one smart contract execution engine instance is required to support transaction parallel execution, so as to avoid the execution overhead of repeatedly processing the same byte code, and occupy less memory. When one thread executes the intelligent contract, the execution environment of the thread keeps memory isolation from the execution environments of other threads, the thread cannot be influenced by other threads executing the intelligent contract, and the memory access result is consistent with the single thread execution result.

Referring to fig. 3, fig. 3 is a block diagram of a contract invoking apparatus in a blockchain system provided in an embodiment of the present application, and only a portion related to the embodiment of the present application is shown for convenience of explanation.

The contract invoking apparatus 300 in the blockchain system includes:

a receiving module 301, configured to receive a first smart contract invoking request;

an obtaining module 302, configured to create a first execution context space corresponding to the first smart contract call request and determine a contract code space corresponding to the first smart contract call request; the contract code space is used for storing a runtime module corresponding to the intelligent contract;

An information determining module 303, configured to determine, based on the contract code space, a target runtime module required by the contract called by the first smart contract call request;

an execution module 304, configured to execute the target runtime module based on the first execution context space.

Different contract code spaces point to the same built-in library code space, and the built-in library code space is used for storing a runtime module corresponding to the set intelligent contract;

the information determining module 303 is specifically configured to:

The information determining module 303 is specifically configured to:

if so, generating an uninitialized runtime module based on the byte code;

If the execution is no, the information determining module 303 is specifically configured to:

if not, applying for a first module initialization lock of the built-in library code space;

If not, judging whether the byte codes corresponding to the target runtime module exist in the built-in library code space; or,

The information determining module 303 is specifically configured to:

after determining whether to load the runtime module corresponding to the target module name in the contract code space, the method further includes:

If so, generating an uninitialized runtime module based on the byte code;

The information determining module 303 is specifically configured to, when executing the byte code corresponding to the target runtime module in the contract code space if the byte code is not loaded, determine whether the byte code exists in the contract code space:

if not, applying for a second module initialization lock of the contract code space;

if not, judging whether byte codes corresponding to the target runtime module exist in the contract code space; or,

The information determining module 303 is specifically configured to:

after determining whether to load the runtime module corresponding to the target module name in the dynamic code space, the method further includes:

if so, generating an uninitialized runtime module based on the byte code;

The first execution context space comprises a static field space, wherein the static field space is used for storing contract code static field parameters corresponding to contracts called by the first intelligent contract calling request;

The information determining module 303 is specifically configured to:

Wherein, the execution module 304 is specifically configured to:

The acquiring module 302 is specifically configured to:

if a second execution context space corresponding to a second intelligent contract calling request exists in the memory, opening up other spaces from the memory as the first execution context space corresponding to the first intelligent contract calling;

The contract calling device in the blockchain system provided by the embodiment of the invention can realize the processes of the embodiment of the contract calling method in the blockchain system, and can achieve the same technical effect, and in order to avoid repetition, the description is omitted here.

Fig. 4 is a block diagram of a computer device according to an embodiment of the present application. As shown in the figure, the computer device 4 of this embodiment includes: at least one processor 40 (only one is shown in fig. 4), a memory 41 and a computer program 42 stored in the memory 41 and executable on the at least one processor 40, the processor 40 implementing the steps in any of the various method embodiments described above when executing the computer program 42.

The computer device 4 may be a desktop computer, a notebook computer, a palm computer, a cloud server, or the like. The computer device 4 may include, but is not limited to, a processor 40, a memory 41. It will be appreciated by those skilled in the art that fig. 4 is merely an example of computer device 4 and is not intended to limit computer device 4, and may include more or fewer components than shown, or may combine certain components, or different components, e.g., the computer device may also include input and output devices, network access devices, buses, etc.

The processor 40 may be a central processing unit (Central Processing Unit, CPU), but may also be other general purpose processors, digital signal processors (Digital Signal Processor, DSP), application specific integrated circuits (Application Specific Integrated Circuit, ASIC), field programmable gate arrays (Field-Programmable Gate Array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

The memory 41 may be an internal storage unit of the computer device 4, such as a hard disk or a memory of the computer device 4. The memory 41 may also be an external storage device of the computer device 4, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card) or the like, which are provided on the computer device 4. Further, the memory 41 may also include both an internal storage unit and an external storage device of the computer device 4. The memory 41 is used for storing the computer program and other programs and data required by the computer device. The memory 41 may also be used for temporarily storing data that has been output or is to be output.

It will be apparent to those skilled in the art that, for convenience and brevity of description, only the above-described division of the functional units and modules is illustrated, and in practical application, the above-described functional distribution may be performed by different functional units and modules according to needs, i.e. the internal structure of the apparatus is divided into different functional units or modules to perform all or part of the above-described functions. The functional units and modules in the embodiment may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit, where the integrated units may be implemented in a form of hardware or a form of a software functional unit. In addition, specific names of the functional units and modules are only for convenience of distinguishing from each other, and are not used for limiting the protection scope of the present application. The specific working process of the units and modules in the above system may refer to the corresponding process in the foregoing method embodiment, which is not described herein again.

In the foregoing embodiments, the descriptions of the embodiments are emphasized, and in part, not described or illustrated in any particular embodiment, reference is made to the related descriptions of other embodiments.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

In the embodiments provided in this application, it should be understood that the disclosed apparatus/computer device and method may be implemented in other ways. For example, the apparatus/computer device embodiments described above are merely illustrative, e.g., the division of the modules or units is merely a logical function division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection via interfaces, devices or units, which may be in electrical, mechanical or other forms.

The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in each embodiment of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.

The integrated modules/units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the present application may implement all or part of the flow of the method of the above embodiment, or may be implemented by a computer program to instruct related hardware, where the computer program may be stored in a computer readable storage medium, and when the computer program is executed by a processor, the computer program may implement the steps of each method embodiment described above. Wherein the computer program comprises computer program code which may be in source code form, object code form, executable file or some intermediate form etc. The computer readable medium may include: any entity or device capable of carrying the computer program code, a recording medium, a U disk, a removable hard disk, a magnetic disk, an optical disk, a computer Memory, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), an electrical carrier signal, a telecommunications signal, a software distribution medium, and so forth. It should be noted that the computer readable medium contains content that can be appropriately scaled according to the requirements of jurisdictions in which such content is subject to legislation and patent practice, such as in certain jurisdictions in which such content is subject to legislation and patent practice, the computer readable medium does not include electrical carrier signals and telecommunication signals.

The present application may also implement all or part of the flow of the method of the above embodiments, and may also be implemented by a computer program product, which when run on a computer device, causes the computer device to implement the steps in the method embodiments described above.

The above embodiments are only for illustrating the technical solution of the present application, and are not limiting; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present application, and are intended to be included in the scope of the present application.

Claims

1. A contract invoking method in a blockchain system, comprising:

receiving a first intelligent contract call request;

2. The method of claim 1, wherein different ones of the contract code spaces point to a same built-in library code space for storing runtime modules corresponding to set-up smart contracts;

the determining, based on the contract code space, a target runtime module required by the first smart contract call request to call a contract includes:

3. The method of claim 2, wherein the extracting, based on the contract code space, a target runtime module required by the contract invoked by the first smart contract invocation request from the built-in library code space comprises:

if so, generating an uninitialized runtime module based on the byte code;

4. The method of claim 3, wherein if no, determining whether the bytecode corresponding to the target runtime module exists in the built-in library code space comprises:

5. The method of claim 2, wherein the extracting from the contract code space a target runtime module required by the contract invoked by the first smart contract invocation request comprises:

6. The method of claim 5, wherein the determining whether the runtime module corresponding to the target module name is loaded in the contract code space further comprises:

if so, generating an uninitialized runtime module based on the byte code;

7. The method of claim 6, wherein the determining whether the bytecode corresponding to the target runtime module exists in the contract code space if not loaded comprises:

8. The method of claim 2, wherein the extracting, based on the contract code space, a target runtime module required by the contract invoked by the first smart contract invocation request from dynamic code space comprises:

9. The method of claim 8, wherein said determining whether a runtime module corresponding to said target module name is loaded in said dynamic code space further comprises:

if so, generating an uninitialized runtime module based on the byte code;

10. The method of claim 3, 6 or 9, wherein the first execution context space comprises a static field space for storing contract code static field parameters corresponding to a contract invoked by the first smart contract invocation request;

the initializing process is performed on the uninitialized runtime module to obtain the target runtime module, which comprises the following steps:

11. The method of claim 1, wherein after executing the target runtime module based on the first execution context space, further comprising:

12. The method of claim 1, wherein the creating a first execution context space corresponding to the first smart contract invocation request and determining a contract code space corresponding to the first smart contract invocation request, comprises:

13. A contract invoking apparatus in a blockchain system, comprising:

14. A computer device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, characterized in that the processor implements the steps of the method according to any of claims 1 to 12 when the computer program is executed.

15. A computer readable storage medium storing a computer program, characterized in that the computer program when executed by a processor implements the steps of the method according to any one of claims 1 to 12.