Method and apparatus for reading data from and writing data to external systems by virtual machines

Abstract

This invention discloses a method and apparatus for a virtual machine to read data from an external system and write data, relating to the field of computer technology. One specific implementation of the method includes: creating an address buffer within a smart contract running on the virtual machine; using the storage address of external data as an input parameter of the smart contract; reading external data from the storage address of the external data into the address buffer; wherein the storage address is of integer type; enabling the transfer of complex external data types to the smart contract executed by the Webassembly virtual machine. Another specific implementation includes: using the data address of the address buffer as an output parameter of the smart contract running on the virtual machine; passing the data address to an external system; wherein the output parameter is of integer type; after the external system creates an external buffer, copying the data from the data address to the external buffer; enabling the transfer of complex data types from the Webassembly virtual machine smart contract to the external system.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method for a virtual machine to read data from an external system, as well as a related method and apparatus for writing data. Background Technology

[0002] Webassembly is not a language, but a new bytecode format. It is a binary instruction format based on a stack-based virtual machine, designed to be directly compiled into Webassembly intermediate bytecode using high-level languages ​​(such as C / C++ / Rust). Initially, Webassembly was mainly used in web applications, but as it has continued to develop, more and more projects are using it as the final format for smart contracts, loading and running it using a virtual machine that supports Webassembly. The actual parsing and execution of Webassembly bytecode takes place in the core virtual machine module.

[0003] Webassembly-based virtual machines have significantly improved in speed and performance, and support multiple high-level development languages. The Webassembly virtual machine restricts the Webassembly bytecode to run in a secure sandbox execution environment. The Webassembly virtual machine standard only supports integer and floating-point type operations. Since floating-point type operation is an approximate operation, the Webassembly virtual machine that actually runs smart contracts is trimmed to only support integer type operations.

[0004] In the process of realizing this invention, the inventors discovered at least the following problems in the prior art:

[0005] It is not possible to pass complex data types from outside to the smart contract executed by the Webassembly virtual machine, and it is not supported to pass complex data types from inside the smart contract to the external system. Summary of the Invention

[0006] In view of this, embodiments of the present invention provide a method, a data writing method, and an apparatus for a virtual machine to read data from an external system, which can realize the transfer of complex data types from the outside to the smart contract executed by the Webassembly virtual machine, and can transfer complex data types from the Webassembly virtual machine smart contract to the external system of the virtual machine.

[0007] To achieve the above objectives, according to one aspect of the present invention, a method for a virtual machine to read data from an external system is provided.

[0008] A method for a virtual machine to read data from an external system includes: creating an address buffer inside a smart contract running on the virtual machine, wherein the virtual machine is a Webassembly virtual machine; using the storage address of the external data as an input parameter of the smart contract, reading the external data from the storage address of the external data into the address buffer, wherein the storage address is an integer type.

[0009] Optionally, it may also include: creating a length buffer within the smart contract, the length buffer being used to store the length of the address buffer.

[0010] Optionally, before reading the external data from the storage address of the external data into the address buffer, the process includes: passing an offset to the external system where the external data resides.

[0011] Optionally, reading the external data from the storage address of the external data into the address buffer includes: reading the external data from the external system into the address buffer according to the storage address determined based on the initial address of the external data and the offset.

[0012] Optionally, before reading the external data from the storage address of the external data into the address buffer, the method further includes: passing the address of the length buffer to the external system where the external data is located, so that the external system can calculate the remaining length of the external data to be read based on the buffer length of the external system and the offset, and then write the remaining length to be read into the address of the length buffer.

[0013] Optionally, reading the external data from the storage address of the external data into the address buffer includes: comparing the length of the address buffer with the remaining length to be read; if the length of the address buffer is less than or equal to the remaining length to be read, reading byte content with a length equal to the length of the address buffer from the storage address of the external data and copying it to the address buffer; if the length of the address buffer is greater than the remaining length to be read, reading byte content with a length equal to the remaining length to be read from the storage address of the external data and copying it to the address buffer.

[0014] According to another aspect of the present invention, a method for a virtual machine to write data to an external system is provided.

[0015] A method for a virtual machine to write data to an external system includes: passing the data address to an external system using a data address of an address buffer as an output parameter of a smart contract running on the virtual machine; wherein the virtual machine is a Webassembly virtual machine; and after the external system creates an external buffer, copying the data in the data address to the external buffer.

[0016] Optionally, it further includes: passing the address of the length buffer as an output parameter of the smart contract to the external system, wherein the length buffer stores the length of the address buffer, and the address of the length buffer is used by the external system to read the length of the address buffer and convert it into an integer length, so as to create the external buffer based on the integer length.

[0017] According to another aspect of the present invention, an apparatus for a virtual machine to read data from an external system is provided.

[0018] An apparatus for a virtual machine to read data from an external system, wherein the virtual machine is a Webassembly virtual machine, the apparatus comprising: a buffer creation module for creating an address buffer within a smart contract running on the virtual machine; and a data reading module for reading external data from the storage address of the external data into the address buffer, wherein the storage address is an integer type, using the storage address of the external data as an input parameter of the smart contract.

[0019] Optionally, the buffer creation module is further configured to: create a length buffer within the smart contract, the length buffer being used to store the length of the address buffer.

[0020] Optionally, it also includes an offset transmission module for transmitting an offset to the external system where the external data is located.

[0021] Optionally, the data reading module is further configured to: read the external data from the external system into the address buffer according to the storage address determined based on the initial address of the external data and the offset.

[0022] Optionally, it also includes a length buffer address passing module, used to pass the address of the length buffer to the external system where the external data is located, so that the external system can calculate the remaining length to be read of the external data based on the buffer length of the external system and the offset, and then write the remaining length to be read into the address of the length buffer.

[0023] Optionally, the data reading module is further configured to: compare the length of the address buffer with the remaining length to be read; if the length of the address buffer is less than or equal to the remaining length to be read, read byte content with a length equal to the length of the address buffer from the storage address of the external data and copy it to the address buffer; if the length of the address buffer is greater than the remaining length to be read, read byte content with a length equal to the remaining length to be read from the storage address of the external data and copy it to the address buffer.

[0024] According to another aspect of the present invention, an apparatus for a virtual machine to write data to an external system is provided.

[0025] An apparatus for writing data from a virtual machine to an external system, wherein the virtual machine is a Webassembly virtual machine, the apparatus comprising: a first address passing module, configured to pass the data address to the external system using the data address of an address buffer as an output parameter of a smart contract running on the virtual machine; wherein the output parameter is of integer type; and a data writing module, configured to copy the data in the data address to the external buffer after the external system creates an external buffer.

[0026] Optionally, it also includes a second address passing module, used to: pass the address of the length buffer as an output parameter of the smart contract to the external system, wherein the length buffer stores the length of the address buffer, and the address of the length buffer is used by the external system to read the length of the address buffer and convert it into an integer length, so as to create the external buffer according to the integer length.

[0027] According to another aspect of the present invention, an electronic device is provided.

[0028] An electronic device includes: one or more processors; and a memory for storing one or more programs, which, when executed by the one or more processors, cause the one or more processors to implement the method provided in the embodiments of the present invention for a virtual machine to read data from an external system or for a virtual machine to write data to an external system.

[0029] According to another aspect of the present invention, a computer-readable medium is provided.

[0030] A computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the method provided in the embodiments of the present invention for a virtual machine to read data from an external system or a method for a virtual machine to write data to an external system.

[0031] One embodiment of the above invention has the following advantages or beneficial effects: An address buffer is created inside the smart contract running on the virtual machine. The storage address of external data is used as the input parameter of the smart contract. External data is read from the storage address into the address buffer, where the storage address is an integer type. This enables the transfer of complex external data types to the smart contract executed by the Webassembly virtual machine. The data address in the address buffer is used as the output parameter of the smart contract running on the virtual machine. The data address is passed to the external system, where the output parameter is an integer type. After the external system creates an external buffer, the data at the data address is copied to the external buffer. This enables the transfer of complex data types from the Webassembly virtual machine smart contract to the external system.

[0032] The further effects of the aforementioned unconventional alternative methods will be explained below in conjunction with specific implementation methods. Attached Figure Description

[0033] The accompanying drawings are provided to better understand the invention and are not intended to unduly limit the scope of the invention. Wherein:

[0034] Figure 1 This is a schematic diagram illustrating the main steps of a method for a virtual machine to read data from an external system according to an embodiment of the present invention;

[0035] Figure 2 This is a schematic diagram of a Webassembly virtual machine smart contract framework according to an embodiment of the present invention;

[0036] Figure 3 This is a schematic diagram of a virtual machine native method read framework according to an embodiment of the present invention;

[0037] Figure 4 This is a schematic diagram of the virtual machine native method read timing according to an embodiment of the present invention;

[0038] Figure 5 This is a schematic diagram illustrating the main steps of a method for a virtual machine to write data to an external system according to an embodiment of the present invention.

[0039] Figure 6 This is a schematic diagram of a virtual machine native method writing framework according to an embodiment of the present invention;

[0040] Figure 7 This is a timing diagram of a virtual machine native method write according to an embodiment of the present invention;

[0041] Figure 8 This is a schematic diagram of the main modules of a device for a virtual machine to read data from an external system according to an embodiment of the present invention;

[0042] Figure 9This is a schematic diagram of the main modules of a device for writing data from a virtual machine to an external system according to an embodiment of the present invention.

[0043] Figure 10 This is an exemplary system architecture diagram in which embodiments of the present invention can be applied;

[0044] Figure 11 This is a schematic diagram of the structure of a computer system suitable for implementing the server of the present invention. Detailed Implementation

[0045] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of the present invention, including various details to aid understanding. These details should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0046] Figure 1 This is a schematic diagram illustrating the main steps of a method for a virtual machine to read data from an external system according to an embodiment of the present invention.

[0047] like Figure 1 As shown, a method for a virtual machine to read data from an external system according to an embodiment of the present invention mainly includes the following steps S101 to S102.

[0048] Step S101: Create an address buffer inside the smart contract running in the virtual machine.

[0049] Step S102: Using the storage address of external data as the input parameter of the smart contract, read the external data from the storage address of the external data into the address buffer, wherein the storage address of the external data used as the input parameter is of integer type.

[0050] The virtual machine in this embodiment of the invention is a Webassembly virtual machine, that is, a virtual machine developed based on Webassembly.

[0051] A length buffer can also be created inside the smart contract to store the length of the address buffer.

[0052] Before reading external data from its storage address into the address buffer, an offset can be passed to the external system where the external data resides. Specifically, this refers to the offset of the binary data that the smart contract needs to read from the external data storage address.

[0053] External data is read into the address buffer from its storage address. Specifically, the external data can be read from the external system into the address buffer according to the storage address determined by the initial address and offset of the external data.

[0054] Before reading external data from its storage address into the address buffer, the address of the length buffer can be passed to the external system where the external data resides. The external system can then calculate the remaining length of the external data to be read based on its buffer length and offset, and write the remaining length to be read into the address of the length buffer.

[0055] External data is read from its storage address into an address buffer. Specifically, the length of the address buffer is compared with the remaining length to be read. If the length of the address buffer is less than or equal to the remaining length, bytes of content equal to the length of the address buffer are read from the storage address of the external data and copied to the address buffer. If the length of the address buffer is greater than the remaining length, bytes of content equal to the remaining length are read from the storage address of the external data and copied to the address buffer. The length of the address buffer can be obtained from the address of the length buffer, and the length of the address buffer obtained from the address of the length buffer can be converted into an integer.

[0056] Figure 2 This is a schematic diagram of a Webassembly virtual machine smart contract framework according to an embodiment of the present invention. Figure 2 As shown, the framework for running smart contracts using the WebAssembly Virtual Machine (Wasm Virtual Machine) can be abstracted as follows: Figure 2 As shown in the diagram, during the execution of a smart contract (or simply contract), data is obtained from input, environment, and I / O. After execution, the contract stores the data in the I / O database or returns the data to the contract caller in the output. Specifically, input contains external data, environment contains external parameters such as the contract caller and contract ID (identifier), which are required for each contract call, I / O is used for loading data from the database and storing data in the database, and output contains the data returned to the external environment after the contract has finished executing.

[0057] During the execution of smart contracts by the Webassembly virtual machine (i.e., the Wasm virtual machine), the smart contract needs to interact with the aforementioned input, environment, output, and I / O through native methods. The native methods specifically involve read and write operations with the aforementioned four external parties.

[0058] The Webassembly instructions executed by the virtual machine only support integer input and output parameters for smart contracts. Therefore, when external input, environment, output, and I / O need to interact with the smart contract, only one method can be used. The input parameter of the smart contract is the storage address of the external data. The storage address can be represented by an integer type, such as a 32-bit int type (basic integer type, i.e., short integer type). Then, the data is read from this address into the smart contract's buffer. The smart contract then deserializes the binary data in the buffer into the actual object according to its own business type for processing. This embodiment of the invention solves the technical problem that the Webassembly virtual machine only supports integer input and output parameters for smart contract methods, thus making it impossible to pass complex external data types to the smart contract executed by the Webassembly virtual machine.

[0059] Because the size of the buffer inside the smart contract differs from the sizes of the external input and output buffers, the virtual machine native method read / write mechanism of this embodiment can also transfer data from the external input buffer to the smart contract's internal buffer, and transfer data from the smart contract's buffer to the external output buffer, even when the sizes of the internal buffer and the external input and output buffers are different. Detailed processes will be further described in the following embodiments.

[0060] Figure 3 This is a schematic diagram of a virtual machine native method read framework according to an embodiment of the present invention. Figure 3As shown, the virtual machine native method read framework in this embodiment implements the virtual machine reading data from an external system to the local machine. The external system is the backend application in this embodiment. The external data is stored in the input buffer of the backend application (i.e., the data buffer of the external system), and the address of the input buffer is the storage address of the external data. The smart contract running in the Webassembly virtual machine has three parameters: addr, len, and offset. addr represents the buffer address of the smart contract, i.e., the data address of the address buffer. len represents the buffer length of the smart contract, i.e., the length of the address buffer. offset represents the offset of the binary data to be read from the input buffer by the smart contract. The read / write direction of offset is that the backend application reads from the smart contract direction of the Webassembly virtual machine, i.e., the Webassembly virtual machine passes the offset to the external system. The buffer read / write direction represented by the len address (i.e., the address of the length buffer) is bidirectional, meaning that the backend application can read from the smart contract direction of the Webassembly virtual machine or write to the smart contract direction of the Webassembly virtual machine. The native method read framework copies the data source from the buffer containing the input to the buffer containing the address buffer of the smart contract within the virtual machine, effectively reading data from an external system to the virtual machine's local storage. When the length of the input buffer and the length of the address buffer (i.e., the length of the address buffer) are inconsistent, multiple read operations are required.

[0061] Figure 4 This is a schematic diagram of the virtual machine native method read timing according to an embodiment of the present invention. Figure 4 The timing of copying external input buffer data to the addr buffer, which is the virtual machine native method read timing of this embodiment, is used to implement the process of the virtual machine reading data from an external system in this embodiment of the invention. Here, the external input buffer data refers to the external data of the external system, which can specifically be a backend application, and the addr buffer is the address buffer created inside the smart contract running on the virtual machine.

[0062] Step S401: The backend application reads the offset value from the virtual machine, with the initial offset value being 0;

[0063] Step S402: The backend application reads the length len from the len buffer address of the virtual machine smart contract;

[0064] Here, the len buffer address is the address of the length buffer. The len buffer is four bytes in length. The backend application converts the read byte content (len length) into an integer length, which represents the length of the addr address of the virtual machine smart contract. This length is marked as addr_len.

[0065] Step S403: Write the remaining length to be read from the input buffer to the address of the len buffer in the virtual machine smart contract;

[0066] The input buffer is the data buffer of the external system. The remaining length of the input buffer to be read is the remaining length to be read, which is calculated using the following formula:

[0067] remainder_length=input_length-offset

[0068] `input_length` is the length of the external system's buffer, specifically the length of the external system's data buffer. `offset` is the offset passed to the external system.

[0069] Step S404: Determine whether addr_len is less than or equal to the remaining length to be read (i.e., input_length - offset value). If yes, proceed to step S405; otherwise, proceed to step S406.

[0070] addr_len is the length of the address buffer.

[0071] Step S405: Read bytes of length addr_len from the input buffer starting at address ptr(input) + offset, and write them into the addr buffer;

[0072] `ptr(input)` is the initial address of the external data. `ptr(input) + offset` is the storage address determined based on the initial address and offset of the external data. This step performs the following operation: read bytes equal to the length of the address buffer `addr_len` from this storage address and copy them to the address buffer `addr buffer`.

[0073] Step S406: Read data of length input_length - offset starting from the address ptr(input) + offset and copy it to the addr buffer;

[0074] That is, if the length of the address buffer is greater than the remaining length to be read, read bytes of content equal to the remaining length to be read from the storage address of the external data and copy them to the address buffer.

[0075] After step S405 or step S406, proceed to step S407.

[0076] Step S407: Update the offset value to offset = offset + addr_len;

[0077] The above timing sequence completes the transfer of data from the external input buffer to the addrbuffer in the smart contract.

[0078] This invention, through the creation of a len buffer and an addr buffer within the smart contract, and by calculating an offset value and passing it to the external system, copies data from the external input buffer (i.e., external data from the external system) into the smart contract's addr buffer. This enables the transfer of complex data structures from the external system to the smart contract within the virtual machine, thus solving the problem that the WebAssembly virtual machine's smart contract methods only support integer input parameters and cannot support the transfer of complex data types from the external system to the internal system.

[0079] Figure 5 This is a schematic diagram illustrating the main steps of a method for a virtual machine to write data to an external system according to an embodiment of the present invention.

[0080] like Figure 5 As shown, a method for writing data from a virtual machine to an external system according to an embodiment of the present invention mainly includes the following steps S501 to S502. The virtual machine in this embodiment of the present invention is a Webassembly virtual machine, that is, a virtual machine developed based on Webassembly.

[0081] Step S501: Use the data address in the address buffer as the output parameter of the smart contract running in the virtual machine to pass the data address to the external system; where the output parameter is of integer type.

[0082] Step S502: After creating an external buffer on the external system, copy the data from the data address to the external buffer.

[0083] The address of the length buffer can also be passed to an external system as an output parameter of the smart contract. The length buffer stores the length of the address buffer. The address of the length buffer is used by the external system to read the length of the address buffer and convert it to an integer length in order to create an external buffer based on the integer length.

[0084] Figure 6 This is a schematic diagram of a virtual machine native method write framework according to an embodiment of the present invention. The virtual machine native method write framework of this embodiment implements the writing of data from the virtual machine to an external system, such as... Figure 6 As shown, data in the virtual machine smart contract's addr buffer is written to an external output buffer, which is an external buffer created by an external system. The external system is... Figure 6 The backend application uses the Wasm virtual machine. In this embodiment, the write logic only needs to pass the smart contract's addr buffer address and the addr buffer's length to the external system; the length of the address buffer is read through the ptr(len) address. The addr buffer address is the data address of the address buffer. The addr buffer's length is the length of the address buffer, which is stored in a length buffer. The address of the length buffer can be passed to the external system. The external system reads the address buffer's length from the length buffer's address (i.e., the ptr(len) address), converts it to an integer length, and creates an external buffer of the corresponding length based on the integer length.

[0085] Figure 7 This is a timing diagram of a virtual machine native method write according to an embodiment of the present invention. Figure 7 The virtual machine native method write sequence shown is the process of a virtual machine writing data to an external system according to an embodiment of the present invention, specifically including:

[0086] Step S701: The virtual machine smart contract writes the addr buffer length into the four-byte content at the address where the len buffer is located.

[0087] The addr buffer is the address buffer created inside the smart contract running in the virtual machine. The addr bufferlength is the length of the address buffer. The len buffer is the length buffer used to store the length of the address buffer.

[0088] Step S702: The virtual machine reads the four-byte content of the ptr(len)buffer and converts the read four-byte content into the corresponding integer length.

[0089] The integer length obtained after conversion represents the length of ptr(addr)buffer, identified by addr_length.

[0090] The virtual machine is outside the external system. ptr(len)buffer is the address of the length buffer. The four bytes of content in it are the length of the address buffer. The external system converts this length into an integer length, which is identified by addr_length.

[0091] Step S703: Allocate an output buffer of length addr_length outside the virtual machine and directly copy the data at address ptr(addr) into the output buffer.

[0092] The output buffer is an external buffer created by the external system. The length of the external buffer is the same as the length of the address buffer. The ptr (addr) address is the data address of the address buffer. Through this step, the data at the data address is copied to the external buffer.

[0093] This invention, through its embodiments, reads the length of the address buffer (addr_length) within the smart contract's internal len buffer and marks the length of the addr buffer as addr_length. An output buffer of length addr_length is allocated in the external system to receive data written out by the contract. This enables the transfer of complex data structures from within the virtual machine smart contract to the outside of the virtual machine, thus solving the problem that the WebAssembly virtual machine's smart contract methods only support integer output parameters and cannot support the transfer of complex data types to external systems.

[0094] Figure 8 This is a schematic diagram of the main modules of a device for a virtual machine to read data from an external system according to an embodiment of the present invention. Figure 8 As shown, a device 800 for a virtual machine to read data from an external system according to an embodiment of the present invention mainly includes: a buffer creation module 801 and a data reading module 802.

[0095] The buffer creation module 801 is used to create address buffers within smart contracts running on a virtual machine.

[0096] The data reading module 802 is used to read external data from the storage address of the external data into the address buffer, where the storage address is an integer type.

[0097] The buffer creation module 801 is also used to: create a length buffer inside the smart contract, which is used to store the length of the address buffer.

[0098] The device 800 for reading data from an external system by a virtual machine may further include an offset transfer module for: transferring an offset to the external system where the external data is located.

[0099] The data reading module 802 can be specifically used to read external data from the external system into the address buffer according to the storage address determined by the initial address and offset of the external data.

[0100] The device 800 for reading data from an external system by a virtual machine may further include a length buffer address passing module, which is used to pass the address of the length buffer to the external system where the external data is located, so that the external system can calculate the remaining length of the external data to be read based on the buffer length and offset of the external system, and then write the remaining length to be read into the address of the length buffer.

[0101] The data reading module 802 is further configured to: compare the length of the address buffer with the remaining length to be read; if the length of the address buffer is less than or equal to the remaining length to be read, read byte content with a length equal to the length of the address buffer from the storage address of the external data and copy it to the address buffer; if the length of the address buffer is greater than the remaining length to be read, read byte content with a length equal to the remaining length to be read from the storage address of the external data and copy it to the address buffer.

[0102] Figure 9 This is a schematic diagram of the main modules of a device for writing data from a virtual machine to an external system according to an embodiment of the present invention. Figure 9 As shown, a device 900 for writing data from a virtual machine to an external system according to an embodiment of the present invention mainly includes: a first address passing module 901 and a data writing module 902.

[0103] The first address passing module 901 is used to pass the data address to an external system, using the data address in the address buffer as the output parameter of the smart contract running on the virtual machine; wherein the output parameter is of integer type.

[0104] The data write module 902 is used to copy data from the data address to the external buffer after an external buffer is created on the external system.

[0105] The device 900 for writing data from a virtual machine to an external system may further include a second address passing module, used to: pass the address of a length buffer as an output parameter of the smart contract to the external system, the length buffer storing the length of the address buffer, and the address of the length buffer being used by the external system to read the length of the address buffer and convert it into an integer length, so as to create an external buffer based on the integer length.

[0106] Furthermore, the specific implementation details of the device for reading data from an external system or the method for writing data from an external system to an external system in the embodiments of the present invention have been described in detail in the above-described method for reading data from an external system or the method for writing data from an external system to an external system, so they will not be repeated here.

[0107] The embodiments of the present invention can remove the limitation that Webassembly only supports integers. Only a serialization and deserialization scheme needs to be customized to complete the transfer of complex data types from inside the virtual machine to outside the system, and from outside the system to inside the virtual machine.

[0108] Figure 10 An exemplary system architecture 1000 is shown, which can be applied to a method for a virtual machine to read data from an external system, a method for a virtual machine to write data to an external system, or an apparatus for a virtual machine to read data from an external system and an apparatus for a virtual machine to write data to an external system.

[0109] like Figure 10 As shown, system architecture 1000 may include terminal devices 1001, 1002, and 1003, network 1004, and server 1005. Network 1004 is used as a medium to provide communication links between terminal devices 1001, 1002, and 1003 and server 1005. Network 1004 may include various connection types, such as wired or wireless communication links or fiber optic cables, etc.

[0110] Users can use terminal devices 1001, 1002, and 1003 to interact with server 1005 via network 1004 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 1001, 1002, and 1003, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0111] Terminal devices 1001, 1002, and 1003 can be various electronic devices with displays and web browsing capabilities, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0112] Server 1005 can be a server that provides various services, such as a backend management server that supports websites browsed by users using terminal devices 1001, 1002, and 1003 (for example only). The backend management server can analyze and process received data such as information query requests, and feed back the processing results (such as query results - for example only) to the terminal devices.

[0113] It should be noted that the methods for reading data from an external system and writing data from an external system provided in the embodiments of the present invention are generally executed by the server 1005. Correspondingly, the devices for reading data from an external system and writing data from an external system are generally located in the server 1005.

[0114] It should be understood that Figure 10 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0115] The following is for reference. Figure 11 It shows a schematic diagram of the structure of a computer system 1100 suitable for implementing the server of the embodiments of this application. Figure 11 The server shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0116] like Figure 11 As shown, the computer system 1100 includes a central processing unit (CPU) 1101, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 1102 or programs loaded from storage section 1108 into random access memory (RAM) 1103. The RAM 1103 also stores various programs and data required for the operation of the system 1100. The CPU 1101, ROM 1102, and RAM 1103 are interconnected via a bus 1104. An input / output (I / O) interface 1105 is also connected to the bus 1104.

[0117] The following components are connected to I / O interface 1105: an input section 1106 including a keyboard, mouse, etc.; an output section 1107 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1108 including a hard disk, etc.; and a communication section 1109 including a network interface card such as a LAN card, modem, etc. The communication section 1109 performs communication processing via a network such as the Internet. A drive 1110 is also connected to I / O interface 1105 as needed. Removable media 1111, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1110 as needed so that computer programs read from them can be installed into storage section 1108 as needed.

[0118] In particular, according to the embodiments disclosed in this invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1109, and / or installed from removable medium 1111. When the computer program is executed by central processing unit (CPU) 1101, it performs the functions defined in the system of this application.

[0119] It should be noted that the computer-readable medium shown in this invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0120] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0121] The modules described in the embodiments of the present invention can be implemented in software or hardware. The described modules can also be housed in a processor; for example, a processor may be described as including a buffer creation module and a data reading module. The names of these modules do not necessarily limit the module itself; for example, a buffer creation module may also be described as "a module for creating an address buffer within a smart contract running on a virtual machine."

[0122] In another aspect, the present invention also provides a computer-readable medium, which may be included in the device described in the above embodiments; or it may exist independently and not assembled into the device. The computer-readable medium carries one or more programs that, when executed by the device, cause the device to include: creating an address buffer within a smart contract running in a virtual machine; reading external data from the storage address of the external data into the address buffer, using the storage address of the external data as an input parameter of the smart contract, wherein the storage address is an integer type. Alternatively, it may include: passing the data address to an external system, using the data address of the address buffer as an output parameter of the smart contract running in the virtual machine; wherein the output parameter is an integer type; and copying the data at the data address to the external buffer after the external system creates an external buffer.

[0123] According to the technical solution of this invention, an address buffer is created inside the smart contract running in the virtual machine. The storage address of external data is used as the input parameter of the smart contract, and external data is read from the storage address into the address buffer. Here, the storage address is an integer type. This enables the transfer of complex external data types to the smart contract executed by the Webassembly virtual machine. The data address in the address buffer is used as the output parameter of the smart contract running in the virtual machine, and the data address is passed to the external system. Here, the output parameter is an integer type. After the external system creates an external buffer, the data at the data address is copied to the external buffer. This enables the transfer of complex data types from inside the virtual machine smart contract to the external system.

[0124] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for a virtual machine to read data from an external system, characterized in that, include: An address buffer is created inside the smart contract running in a virtual machine, which is the Webassembly virtual machine; The storage address of external data is used as the input parameter of the smart contract, and the external data is read from the storage address of the external data into the address buffer, wherein the storage address is an integer type; The method further includes: creating a length buffer inside the smart contract, the length buffer being used to store the length of the address buffer; before reading the external data from the storage address of the external data into the address buffer, passing an offset and the address of the length buffer to the external system where the external data is located, so that the external system can calculate the remaining length of the external data to be read based on the buffer length of the external system and the offset, and then write the remaining length to be read into the address of the length buffer.

2. The method according to claim 1, characterized in that, Reading the external data from its storage address into the address buffer includes: The external data is read from the external system into the address buffer according to the storage address determined based on the initial address and the offset of the external data.

3. The method according to claim 1, characterized in that, The step of reading the external data from its storage address into the address buffer includes: The length of the address buffer is compared with the remaining length to be read. If the length of the address buffer is less than or equal to the remaining length to be read, bytes of content with a length equal to the length of the address buffer are read from the storage address of the external data and copied to the address buffer. If the length of the address buffer is greater than the remaining length to be read, bytes of content with a length equal to the remaining length to be read are read from the storage address of the external data and copied to the address buffer.

4. A method for a virtual machine to write data to an external system, characterized in that, include: The data address in the address buffer is used as the output parameter of the smart contract running in the virtual machine, and the data address is passed to the external system; wherein, the output parameter is of integer type, and the virtual machine is the Webassembly virtual machine; After the external system creates an external buffer, the data at the data address is copied to the external buffer; The address of the length buffer is passed to the external system as an output parameter of the smart contract. The length buffer stores the length of the address buffer. The address of the length buffer is used by the external system to read the length of the address buffer and convert it into an integer length in order to create the external buffer based on the integer length.

5. A device for a virtual machine to read data from an external system, characterized in that, The virtual machine is a WebAssembly virtual machine, and the device includes: A buffer creation module is used to create an address buffer inside a smart contract running on a virtual machine; and to create a length buffer inside the smart contract, wherein the length buffer is used to store the length of the address buffer. The data reading module is used to read the external data into the address buffer from the storage address of the external data as the input parameter of the smart contract, wherein the storage address is an integer type; Offset transmission module, used to: transmit offset to the external system where the external data is located; The length buffer address passing module is used to pass the address of the length buffer to the external system where the external data is located, so that the external system can calculate the remaining length of the external data to be read based on the buffer length of the external system and the offset, and then write the remaining length to be read into the address of the length buffer.

6. The apparatus according to claim 5, characterized in that, The data reading module is also used for: The external data is read from the external system into the address buffer according to the storage address determined based on the initial address and the offset of the external data.

7. The apparatus according to claim 5, characterized in that, The data reading module is also used for: The length of the address buffer is compared with the remaining length to be read. If the length of the address buffer is less than or equal to the remaining length to be read, bytes of content with a length equal to the length of the address buffer are read from the storage address of the external data and copied to the address buffer. If the length of the address buffer is greater than the remaining length to be read, bytes of content with a length equal to the remaining length to be read are read from the storage address of the external data and copied to the address buffer.

8. A device for writing data from a virtual machine to an external system, characterized in that, The virtual machine is a WebAssembly virtual machine, and the device includes: The first address passing module is used to pass the data address of the address buffer as the output parameter of the smart contract running in the virtual machine to an external system; wherein the output parameter is of integer type. The data write-out module is used to copy the data in the data address to the external buffer after the external system creates an external buffer; The second address passing module is used to: pass the address of the length buffer as an output parameter of the smart contract to the external system, wherein the length buffer stores the length of the address buffer, and the address of the length buffer is used by the external system to read the length of the address buffer and convert it into an integer length, so as to create the external buffer according to the integer length.

9. An electronic device, characterized in that, include: One or more processors; Memory, used to store one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the method as described in any one of claims 1-4.

10. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-4.

Images