CN109949156B

CN109949156B - Data processing method and server of blockchain contracts

Info

Publication number: CN109949156B
Application number: CN201910153540.6A
Authority: CN
Inventors: 杨舟; 李升林; 傅志敬; 孙立林
Original assignee: Juzix Technology Shenzhen Co ltd
Current assignee: Juzix Technology Shenzhen Co ltd
Priority date: 2019-02-28
Filing date: 2019-02-28
Publication date: 2024-03-01
Anticipated expiration: 2039-02-28
Also published as: CN109949156A

Abstract

The embodiment of the application discloses a data processing method and a server of a blockchain contract. The method comprises the following steps: receiving a transaction request which is sent by a client and points to a target WASM contract file; inquiring a target file to be executed corresponding to the target WASM contract file from a memory cache; the target to-be-executed file is obtained by analyzing the target WASM contract file; and if the target file to be executed is queried, executing the target file to be executed so as to conduct the transaction aiming at the transaction request. The technical scheme provided by the application can improve the efficiency of executing the WASM contract in the block chain.

Description

Data processing method and server of blockchain contracts

Technical Field

The present disclosure relates to the field of internet technologies, and in particular, to a data processing method and a server for a blockchain contract.

Background

With the continuous development of internet technology, the application of the decentralized blockchain is more and more, and the number of intelligent contracts on the blockchain is more and more. Currently, the smart contracts stored in blockchain are typically WASM contracts compiled in the Web Assemble (WASM) language. Each time when a WASM contract is started on a WASM virtual machine, byte codes of the WASM contract are required to be parsed first to obtain a parsed file, and then the parsed file is executed.

However, at present, the number of intelligent contracts on a blockchain is increasing, and the number of times of starting the WASM contracts on the WASM virtual machine is increasing, if the byte code of the WASM contracts needs to be parsed every time the WASM contracts are started, the starting may be slow, and thus the execution efficiency of the WASM contracts is low.

Thus, there is a need for a solution that more efficiently executes blockchain WASM contracts.

Disclosure of Invention

The embodiment of the application aims to provide a data processing method and a server for a blockchain contract, which can improve the efficiency of executing the WASM contract in the blockchain.

To achieve the above object, an embodiment of the present application provides a data processing method of a blockchain contract, the method including: receiving a transaction request which is sent by a client and points to a target WASM contract file; inquiring a target file to be executed corresponding to the target WASM contract file from a memory cache; the target to-be-executed file is obtained by analyzing the target WASM contract file; and if the target file to be executed is queried, executing the target file to be executed so as to conduct the transaction aiming at the transaction request.

To achieve the above object, embodiments of the present application further provide a server including a memory and a processor, the memory storing a computer program; the computer program, when executed by the processor, performs the steps of: receiving a transaction request which is sent by a client and points to a target WASM contract file; inquiring a target file to be executed corresponding to the target WASM contract file from a memory cache; the target to-be-executed file is obtained by analyzing the target WASM contract file; and if the target file to be executed is queried, executing the target file to be executed so as to conduct the transaction aiming at the transaction request.

From the above, in the present application, a file to be executed corresponding to an issued WASM contract file may be stored in a memory cache in advance, where the target file to be executed is obtained by performing parsing processing on the target WASM contract file. Then, after receiving the transaction request directed to the target WASM contract file from the client, the target to-be-executed file corresponding to the target WASM contract file can be directly queried from the memory cache. If the target file to be executed is queried, the target file to be executed can be directly executed to conduct transaction aiming at the transaction request, and the WASM contract is not required to be analyzed, so that the efficiency of executing the WASM contract in the blockchain can be improved.

Drawings

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

FIG. 1 is a step diagram of a method of data processing for a blockchain contract in an embodiment of the present application;

FIG. 2 is a flow chart of querying a file to be executed in an embodiment of the present application;

FIG. 3 is a flowchart of adding files to be executed in an embodiment of the present application;

FIG. 4 is a flowchart of deleting a file to be executed in an embodiment of the present application;

FIG. 5 is a schematic diagram of a server according to an embodiment of the present application;

Detailed Description

In order to make the technical solutions in the present application better understood by those skilled in the art, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only some embodiments of the present application, but not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are intended to be within the scope of the present disclosure.

The embodiment of the application provides a data processing method of a blockchain contract, which can be applied to system architectures of a client and a server. The client may be, for example, a desktop computer, a tablet computer, a notebook computer, a smart phone, a digital assistant, a smart wearable device, a television with network access function, etc. The client can be provided with a communication module and can be in communication connection with a remote server to realize data transmission with the application server.

In this embodiment, the server may be an electronic device having a data operation, a storage function, and a network interaction function; software running in the electronic device that supports data processing, storage, and network interactions may also be used. The number of application servers is not particularly limited in the present embodiment. The application server may be one server, several servers, or a server cluster formed by several servers.

In this embodiment, in practical application, the contract issuing user may send the WASM (Web Assembly) contract file to the blockchain node, for example, the server, through the client. After receiving the WASM contract file, the server may store the contract file in the blockchain and generate a storage address of the corresponding contract file, and then may feed back the storage address of the contract file to the client, so that when the client initiates a transaction request directed to the contract file, the transaction request may include the storage address of the contract file, and thus, after receiving the transaction request, the server may find the contract file from the storage address.

In this embodiment, after the contract issuing user sends the WASM contract file to the server through the client, the server may analyze the WASM contract file to obtain a corresponding file to be executed. Since the files (modules) to be executed obtained after parsing the same contract are the same in general, the files to be executed corresponding to different WASM contract files issued by each contract issuing user may be stored in the memory cache of the server in advance. In this way, after the client sends a transaction request pointing to the WASM contract file, the server can directly query the file to be executed corresponding to the WASM contract file from the memory cache, without resolving the contract. In this embodiment, the file to be executed generally includes Import interface Data (Import), export interface Data (Export), startup or load Data (Start), global Function variable Data (Global), virtual Memory Data (Memory), constant Data (Data), table Data (tables Elements), internal Function Data (functions), and corresponding Code Data (codes), and so on. In the case of caching, the virtual Memory data (Memory) may not be cached, considering that the virtual Memory data (Memory) may be changed when the file to be executed is executed.

Moreover, considering that more and more intelligent contract files exist at present, storing the contract files in the memory cache completely can cause the memory cache to occupy too much memory, and even exceed the maximum limit of the memory cache. In order to relieve the pressure of the memory cache, files to be executed corresponding to the WASM contract files can be stored in a contract database of the server in advance. Therefore, the corresponding files to be executed can be prevented from still existing in the starting and stopping process of the server, and repeated analysis is not needed. In this embodiment, the contract database may be a data set storing files to be executed. The contract database can adopt any one of MySQL, oracle, DB, sybase and other database formats. The contract database may be deployed on a storage medium in a server.

In this embodiment, each WASM contract file may have a respective data identifier, where the data identifier and the file to be executed may be stored in the memory cache or the contract database in a key-value (key-value pair) manner, so that, by using the provided data identifier, a corresponding file to be executed (Module) may be obtained from the memory cache or the contract database.

The embodiment of the application provides a data processing method of a blockchain contract, and the data processing method of the blockchain contract can be applied to the server. Referring to fig. 1, the data processing method of the blockchain contract may include the following steps.

S11: and receiving a transaction request which is sent by the client and points to the target WASM contract file.

In this embodiment, the transaction request may be a character string written according to a preset rule. Wherein, the preset rule may be a network communication protocol followed between the client and the server. For example, the transaction request may be a string written in accordance with the HTTP protocol. The preset rules may define individual components in the transaction request and the order of arrangement between the individual components.

In this embodiment, the transaction request pointing to the target WASM contract file may refer to an identifier of the target WASM contract file carried in the transaction request. Thus, after receiving a transaction request directed to a target WASM contract file from a client, a server may extract an identification of the target WASM contract file from the transaction request. After the identifier of the target WASM contract file is extracted, the server may read the target to-be-executed file corresponding to the target WASM contract file with the identifier, so as to query the target to-be-executed file corresponding to the target WASM contract file from the memory cache or the contract database later.

In this embodiment, the transaction request may further include interface data and parameter data for the target transaction. In this way, after receiving the transaction request directed to the target WASM contract file sent by the client, if the server subsequently queries the target to-be-executed file corresponding to the target WASM contract file from the memory cache or the contract database, the target to-be-executed file can be executed by combining the interface data and the parameter data read from the transaction request, so as to perform the transaction aiming at the transaction request.

S13: inquiring a target file to be executed corresponding to the target WASM contract file from a memory cache; the target to-be-executed file is obtained by analyzing the target WASM contract file.

In this embodiment, after receiving a transaction request sent by a client and directed to a target WASM contract file, the server may query, from a memory cache, a target to-be-executed file corresponding to the target WASM contract file according to an identifier of the target WASM contract file carried in the transaction request. The target to-be-executed file is obtained by analyzing the target WASM contract file. The parsing process may be a pre-parsing process when the contract issuing user issues a contract file or creates the contract, and after the pre-parsing process, the parsed file is stored in the memory cache.

S15: and if the target file to be executed is queried, executing the target file to be executed so as to conduct the transaction aiming at the transaction request.

In this embodiment, as shown in fig. 2, if the target file to be executed can be queried from the memory cache, the queried result can be fed back to the server. And then, the server can read the target file to be executed from the linked list queue of the memory cache, so that the target file to be executed can be executed to conduct the transaction aiming at the transaction request.

In one embodiment, considering that the target to-be-executed file may not be queried from the memory cache, for this reason, since the storage space of the contract database is generally relatively large, and the stored to-be-executed file is relatively comprehensive, if the target to-be-executed file is not queried from the memory cache, as shown in fig. 2, the query of the target to-be-executed file from the contract database may be continued. If the target to-be-executed file is queried from the contract database, the target to-be-executed file can be added into the memory cache, and the queried result can be fed back to the server so that the next time can be queried directly from the memory cache. If the target to-be-executed file is not queried from the contract database, the queried result can be fed back to the server, so that the server can add the target to-be-executed file into the memory cache and the contract database later.

In one embodiment, in practical application, considering that new WASM contract files will appear continuously, the files to be executed corresponding to the new WASM contract files need to be added into a memory cache or a contract database. Therefore, after receiving the specified WASM contract file issued by the client, the server may first analyze the specified WASM contract file to obtain a corresponding specified file to be executed. Next, as shown in fig. 3, it may be determined whether the specified file to be executed exists in the memory cache, and if not, the specified file to be executed may be added to the memory cache. If the file exists, the old appointed to-be-executed file can be deleted, and the appointed to-be-executed file is added into the memory cache again. For example, in general, the files to be executed may be sequentially added and stored from the head of the linked list queue in the memory cache according to the order of the release time or the reading frequency. Then the specified to-be-executed file may be added to the head of the linked list queue of the memory cache. After the specified to-be-executed file is added to the memory cache, serializing processing may be performed on the specified to-be-executed file, and the specified to-be-executed file after serializing processing may be written into a contract database. Then, it may also be determined whether the cache size of the memory cache is greater than or equal to a specified cache size threshold. The specified buffer quantity threshold value can be set according to practical application conditions, for example, can be 70% -100% of the maximum buffer quantity of the memory buffer. And if the data is larger than the specified threshold, releasing the memory cache so that the cache quantity of the memory cache is smaller than the specified threshold. For example, the file to be executed at the tail of the linked list queue of the memory cache may be deleted, or the file to be executed with longer release time or lower reading frequency may be deleted.

In an embodiment, in practical application, considering that some files to be executed may be deleted, for this purpose, as shown in fig. 4, it may be determined whether the files to be executed to be deleted exist in the memory cache for the files to be executed to be deleted. If the file to be deleted exists, the file to be deleted can be deleted from the memory cache, and the file to be deleted to be executed can be deleted from a contract database. If not, the file to be deleted can be deleted from the contract database. So as to keep the memory cache and the files to be deleted in the contract database to be deleted, and prevent inconsistent abnormal conditions.

In this embodiment, the functions implemented in the above-described method steps may be implemented by a computer program, which may be stored in a computer storage medium. In particular, the computer storage medium may be coupled to a processor, which may thereby read a computer program in the computer storage medium. The computer program, when executed by a processor, may implement the steps of:

s11: receiving a transaction request which is sent by a client and points to a target WASM contract file;

s13: inquiring a target file to be executed corresponding to the target WASM contract file from a memory cache; the target to-be-executed file is obtained by analyzing the target WASM contract file;

In one embodiment, when the computer program is executed by a processor, the following steps may be further implemented when the computer program is executed by the processor:

if the target file to be executed is not inquired from the memory cache, inquiring the target file to be executed from a contract database;

if the target file to be executed is queried, the target file to be executed is added into the memory cache.

In one embodiment, the computer program when executed by the processor further performs the steps of:

receiving a designated WASM contract file issued by the client;

analyzing the designated WASM contract file to obtain a corresponding designated file to be executed;

judging whether the specified file to be executed exists in the memory cache, and if not, adding the specified file to be executed into the memory cache.

judging whether the cache quantity of the memory cache is larger than or equal to a specified cache quantity threshold value;

and if the data is larger than the specified threshold, releasing the memory cache so that the cache quantity of the memory cache is smaller than the specified threshold.

carrying out serialization processing on the appointed file to be executed;

and writing the specified files to be executed after the serialization processing into a contract database.

judging whether the file to be deleted exists in the memory cache or not according to the file to be deleted;

if the file to be deleted exists, deleting the file to be deleted from the memory cache, and deleting the file to be deleted from a contract database;

and if the file to be deleted does not exist, deleting the file to be executed from the contract database.

It should be noted that, the functions that can be implemented by the computer program in the computer storage medium may refer to the foregoing implementation manner of the method applied to the terminal device, and the technical effects that are implemented are similar to those that are implemented in the foregoing implementation manner of the method, which will not be described herein again.

Referring to fig. 5, the present application further provides a server. The server comprises a memory and a processor, the memory is used for storing a computer program; the computer program, when executed by the processor, performs the steps of:

In this embodiment, the memory may include physical means for storing information, typically by digitizing the information and then storing the information in a medium using electrical, magnetic, or optical methods. The memory according to the present embodiment may further include: means for storing information by means of electrical energy, such as RAM, ROM, etc.; devices for storing information by magnetic energy, such as hard disk, floppy disk, magnetic tape, magnetic core memory, bubble memory, and USB flash disk; devices for storing information optically, such as CDs or DVDs. Of course, there are other ways of storing, such as quantum storing, graphene storing, etc.

In this embodiment, the processor may be implemented in any suitable manner. For example, the processor may take the form of, for example, a microprocessor or processor, and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, application specific integrated circuits (Application Specific Integrated Circuit, ASIC), a programmable logic controller, and an embedded microcontroller, among others.

receiving a designated WASM contract file issued by the client;

carrying out serialization processing on the appointed file to be executed;

The specific functions implemented by the memory and the processor of the server provided in the embodiments of the present disclosure may be explained in comparison with the foregoing embodiments in the present disclosure, and may achieve the technical effects of the foregoing embodiments, which will not be repeated herein.

In the 90 s of the 20 th century, improvements to one technology could clearly be distinguished as improvements in hardware (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) or software (improvements to the process flow). However, with the development of technology, many improvements of the current method flows can be regarded as direct improvements of hardware circuit structures. Designers almost always obtain corresponding hardware circuit structures by programming improved method flows into hardware circuits. Therefore, an improvement of a method flow cannot be said to be realized by a hardware entity module. For example, a programmable logic device (Programmable Logic Device, PLD) (e.g., field programmable gate array (Field Programmable Gate Array, FPGA)) is an integrated circuit whose logic function is determined by the programming of the device by a user. A designer programs to "integrate" a digital system onto a PLD without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Moreover, nowadays, instead of manually manufacturing integrated circuit chips, such programming is mostly implemented by using "logic compiler" software, which is similar to the software compiler used in program development and writing, and the original code before the compiling is also written in a specific programming language, which is called hardware description language (Hardware Description Language, HDL), but not just one of the hdds, but a plurality of kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), lava, lola, myHDL, PALASM, RHDL (Ruby Hardware Description Language), etc., VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog are currently most commonly used. It will also be apparent to those skilled in the art that a hardware circuit implementing the logic method flow can be readily obtained by merely slightly programming the method flow into an integrated circuit using several of the hardware description languages described above.

Those skilled in the art will also appreciate that, in addition to implementing clients, servers in the form of pure computer readable program code, it is well possible to implement the same functions by logically programming method steps such that clients, servers are implemented in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, and the like. Such clients, servers may therefore be considered as a hardware component, and the means included therein for performing various functions may also be considered as structures within the hardware component. Or even means for achieving the various functions may be regarded as either software modules implementing the methods or structures within hardware components.

From the above description of embodiments, it will be apparent to those skilled in the art that the present application may be implemented in software plus a necessary general purpose hardware platform. Based on such understanding, the technical solutions of the present application may be embodied essentially or in a part contributing to the prior art in the form of a software product, which may be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to perform the methods described in the embodiments or some parts of the embodiments of the present application.

In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are referred to each other, and each embodiment is mainly described as different from other embodiments. In particular, for embodiments of computer storage media, servers, and clients, reference may be made to the description of embodiments of the foregoing methods for comparison explanation.

The application may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The application may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

Although the present application has been described by way of embodiments, those of ordinary skill in the art will recognize that there are many variations and modifications of the present application without departing from the spirit of the present application, and it is intended that the appended claims encompass such variations and modifications without departing from the spirit of the present application.

Claims

1. A method of data processing for a blockchain contract, the method comprising:

receiving a transaction request which is sent by a client and points to a target WASM contract file; the transaction request carries the identification of the target WASM contract file, interface data and parameter data for target transaction;

inquiring a target to-be-executed file corresponding to the target WASM contract file with the identifier from a linked list queue of a memory cache; the target to-be-executed file is obtained by pre-analyzing the target WASM contract file when a contract issuing user issues the target WASM contract file or creates a contract in the target WASM contract file, and is pre-stored in a linked list queue of the memory cache;

if the target file to be executed is queried, executing the target file to be executed by combining the interface data and the parameter data read from the transaction request so as to conduct transaction aiming at the transaction request;

wherein the method further comprises:

receiving a designated WASM contract file issued by the client;

2. The method according to claim 1, wherein the method further comprises:

3. The method of claim 1, wherein after adding the specified to-be-executed file to the memory cache, the method further comprises:

4. The method of claim 1, wherein after adding the specified to-be-executed file to the memory cache, the method further comprises:

carrying out serialization processing on the appointed file to be executed;

5. The method according to claim 1, wherein the method further comprises:

6. A server comprising a memory and a processor, the memory for storing a computer program; the computer program, when executed by the processor, performs the steps of:

inquiring a target to-be-executed file corresponding to the target WASM contract file with the identifier from a linked list queue of a memory cache; the target to-be-executed file is a linked list queue which is obtained by pre-analyzing the target WASM contract file and pre-stored in the memory cache when a contract issuing user issues the target WASM contract file or creates a contract in the target WASM contract file;

the computer program, when executed by the processor, further performs the steps of:

receiving a designated WASM contract file issued by the client;

7. The server of claim 6, the computer program, when executed by the processor, further implementing the steps of:

8. The server of claim 6, the computer program, when executed by the processor, further implementing the steps of:

9. The server of claim 6, the computer program, when executed by the processor, further implementing the steps of:

carrying out serialization processing on the appointed file to be executed;

10. The server of claim 6, the computer program, when executed by the processor, further implementing the steps of: