Data processing method, device, medium and program product

Abstract

The present application provides a data processing method, device, medium, and program product, relating to the blockchain technology field of financial technology. The method includes: obtaining a smart contract invoked by a user-initiated transaction, converting the smart contract into an opcode and obtaining a target opcode, determining the target access area of ​​the function in the smart contract in the storage space based on the target opcode, determining the blockchain shard corresponding to the target access area based on a preset correspondence, and allocating the transaction to the blockchain shard for processing. In this technical solution, by segmenting the storage space, different access areas correspond to different blockchain shards. When a large number of transactions simultaneously invoke the same smart contract, different blockchain shards can also be selected for processing based on their corresponding access areas, thereby improving the throughput of the blockchain system.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology in financial technology, and in particular to a data processing method, device, medium and program product. Background Art

[0002] With the development of computer technology, more and more technologies are being applied in the financial sector. Traditional finance is gradually shifting towards FinTech, and blockchain technology is no exception. However, the financial industry's security and real-time requirements place higher demands on blockchain technology. Blockchain systems typically execute all transactions serially on each full node, then reach a consensus across the entire network to maintain the consistency of ledger data stored by each node. This achieves complete decentralization at the expense of performance. Limited by network bandwidth, node CPU processing power, and disk read / write capabilities, the throughput of the entire blockchain system is limited.

[0003] In order to improve throughput, existing technologies usually divide block-producing nodes into multiple smaller committees to address network bandwidth limitations. Each committee processes received transactions in parallel, reducing the propagation range of blocks to improve the throughput of the blockchain.

[0004] However, since this method allocates read and write permissions for a portion of the account status to each blockchain shard based on the smart contract account, when a large number of users simultaneously initiate transactions to call a smart contract, since they all change the storage space of the same smart contract, these transactions will be assigned to the same blockchain shard for processing, which will cause transaction congestion and reduce the throughput of the blockchain system. Summary of the Invention

[0005] The present application provides a data processing method, device, medium, and program product for solving the problem of low throughput of existing blockchain systems.

[0006] In a first aspect, an embodiment of the present application provides a data processing method applied to a blockchain platform with a smart contract function, the method comprising:

[0007] Obtain the smart contract invoked by the user-initiated exchange and convert the smart contract into an opcode;

[0008] Obtaining a target opcode from the opcode, where the target opcode is an opcode for accessing a storage space of the blockchain platform, where the storage space is divided into at least two access areas;

[0009] Determine, according to the target opcode, a target access area of ​​the function in the smart contract in the storage space;

[0010] Determine, based on a preset correspondence, a blockchain shard corresponding to the target access area, wherein the blockchain shard includes at least one node, and the preset correspondence includes a blockchain shard corresponding to each access area;

[0011] The transaction is assigned to the blockchain shard for processing.

[0012] In a possible design of the first aspect, determining, based on the target opcode, a target access area of ​​the function in the smart contract in the storage space of the blockchain platform includes:

[0013] Obtain the element stored at the top of the stack before the target opcode is executed;

[0014] A target access area of ​​the function in the storage space is determined according to the element.

[0015] In another possible design of the first aspect, determining, based on the element, a target access area of ​​the function in the storage space includes:

[0016] Determining whether the value of the element is a constant;

[0017] If the value of the element is a constant, the constant is used as the target access area of ​​the function in the storage space.

[0018] In yet another possible design of the first aspect, determining, based on the element, a target access area of ​​the function in the storage space includes:

[0019] Determine whether the value of the element is an environment parameter / function parameter;

[0020] If the value of the element is the environment parameter / function parameter, obtaining derivation information of the target region, where the derivation information is obtained by decompiling the smart contract, and includes at least one of the stack state, function boundaries, function parameters, and the loading location and information flow of environment information before the execution of the target opcode;

[0021] The target access area is determined according to the deduction information, the first preset deduction rule corresponding to the environmental parameter / the second preset deduction rule corresponding to the function parameter.

[0022] In another possible design of the first aspect, if the element is the environmental parameter, determining the target access area according to the derivation information and a first preset derivation rule corresponding to the environmental parameter includes:

[0023] Determining, based on the derivation information, whether a function signature of the function includes an identification operation code and the identification operation code is an operation code for obtaining environment parameters;

[0024] If the function includes the identification operation code and the identification operation code is an operation code for obtaining the environment parameter, the target access area is determined according to the environment parameter.

[0025] In another possible design of the first aspect, if the element is a function parameter, determining the target access area according to the derivation information and a second preset derivation rule corresponding to the function parameter includes:

[0026] Determining, based on the derivation information, whether the function signature of the function satisfies a preset condition and whether the function parameters have been loaded at a preset location;

[0027] If the function signature of the function meets a preset condition and the function parameters have been loaded at a preset position, the target access area is determined according to the function parameters.

[0028] In another possible design of the first aspect, obtaining the element stored at the top of the stack before executing the target opcode includes:

[0029] Obtaining the position and opcode parameters of each opcode, and combining each opcode, the position and the opcode parameters to obtain an opcode sequence;

[0030] Divide each opcode sequence into blocks and determine the basic block in which each opcode sequence is located;

[0031] Perform stack analysis on each basic block to determine the elements in the stack before and after each opcode is executed;

[0032] Determine the connection relationship between each basic block and construct a control flow graph;

[0033] According to the control flow graph, the element stored at the top of the stack before the target opcode is executed is obtained.

[0034] In another possible design of the first aspect, the method further includes:

[0035] Obtaining, according to the control flow graph, a boundary of the function in the smart contract, wherein the boundary includes an entry position and an end position of the function;

[0036] According to the boundary of the function, it is determined whether the function contains the target operation code.

[0037] In another possible design of the first aspect, the method further includes:

[0038] Get transactions assigned to the same blockchain shard and transactions assigned to different blockchain shards;

[0039] Control the serial processing of transactions assigned to the same blockchain shard;

[0040] Controls parallel processing of transactions assigned to different blockchain shards.

[0041] In another possible design of the first aspect, the method further includes:

[0042] Obtaining a first transaction and a second transaction, where the smart contracts invoked by the first transaction and the second transaction have the same access area in the storage space of the blockchain platform;

[0043] The first transaction and the second transaction are read and written uniformly.

[0044] In a second aspect, an embodiment of the present application provides a computer device, comprising: a processor, and a memory communicatively connected to the processor;

[0045] The memory stores computer-executable instructions;

[0046] The processor executes the computer-executable instructions stored in the memory to implement the above method.

[0047] In a third aspect, an embodiment of the present application provides a readable storage medium, in which computer instructions are stored. When the computer instructions are executed by a processor, they are used to implement the above method.

[0048] In a fourth aspect, an embodiment of the present application provides a program product, comprising computer instructions, which implement the above method when executed by a processor.

[0049] The data processing method, device, medium, and program product provided in the embodiments of the present application divide the storage space into segments, and different access areas correspond to different blockchain shards. When a large number of transactions simultaneously call the same smart contract, different blockchain shards can also be selected for processing based on their corresponding access areas, thereby improving the throughput of the blockchain system. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application;

[0051] Figure 1 A schematic diagram of the structure of the blockchain platform provided in the embodiment of this application;

[0052] Figure 2A flowchart of a data processing method provided in an embodiment of the present application;

[0053] Figure 3 A schematic diagram of basic block division provided in an embodiment of the present application;

[0054] Figure 4 A schematic diagram of the derivation information output by the decompilation of the smart contract provided in an embodiment of the present application;

[0055] Figure 5 A schematic diagram of the derivation rules provided in the embodiment of the present application;

[0056] Figure 6 A schematic diagram of the structure of a data processing device provided in an embodiment of the present application;

[0057] Figure 7 A schematic diagram of the structure of a computer device provided in an embodiment of the present application.

[0058] The above drawings illustrate specific embodiments of the present application, which will be described in more detail below. These drawings and the textual description are not intended to limit the scope of the present application in any way, but rather to illustrate the concepts of the present application to those skilled in the art by reference to specific embodiments. DETAILED DESCRIPTION

[0059] To make the purpose, technical solutions, and advantages of the embodiments of this application more clear, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0060] First, let’s explain the terms involved in this application:

[0061] Blockchain:

[0062] Blockchain is a distributed, decentralized computing and storage architecture that provides the foundation for building a secure, stable, reliable, and highly available (accessible anywhere, anytime) ledger that records asset changes. This allows for the direct, trusted transfer of value (e.g., electronic currency, electronic assets, device access rights, etc.) without third parties. Blockchain consists of three basic elements: transactions, blocks, and chains. Transactions trigger changes in the ledger's state; blocks record transactions and their status over a period of time; and chains record all state changes in the blockchain, constructed by cryptographically linking blocks in the order they occurred.

[0063] Smart Contracts:

[0064] A smart contract is an account on the blockchain that contains contract code and storage space. The smart contract's behavior is controlled by the contract code, and its state is stored in the contract's storage space. Contract code can be thought of as an object in object-oriented programming. Writing contract code is similar to writing a class, where you can define various variables and functions. When you deploy the contract code to the blockchain, it's like creating an object for the class. Once the contract code is uploaded to the blockchain, you obtain a contract address, which acts as a pointer to the contract. When you call a contract, you send a transaction to this contract address and specify the function name and parameters to invoke, causing the contract to execute the corresponding logic.

[0065] Ethereum:

[0066] Ethereum is a blockchain platform with smart contract capabilities. Each full Ethereum node contains an Ethereum Virtual Machine (EVM). When a node needs to package or verify a block, it executes the contract code associated with the transaction into the EVM. The execution results update the Ethereum account's storage and are recorded on the blockchain. Ethereum contract code is stored on the blockchain in machine code, with each byte of machine code representing an operation. The Ethereum contract code header typically contains a function selector. The EVM selects the appropriate contract code snippet to execute based on the function signature and parameters passed in the transaction. Ethereum's storage space is a superarray with a capacity of 2^256. Each element in the array is called a slot and has an initial value of 0. This storage space stores the state variables of the contract code. For state variables with known length (fixed-length integers, addresses, fixed-length floating-point types, fixed-length byte arrays), their storage location is specified during contract compilation. For state variables with undefined length (dynamic arrays, mappings), the storage location is calculated according to specific rules for each state variable in the contract code.

[0067] Figure 1 A schematic diagram of the structure of the blockchain platform provided in the embodiment of this application is shown in FIG. Figure 1As shown in the figure, taking Ethereum as an example, all full nodes in Ethereum execute all transactions serially, and then reach a consensus across the entire network to maintain the consistency of the ledger data stored by each node. This achieves complete decentralization at the expense of performance, which makes the throughput of the blockchain system extremely low (the Bitcoin blockchain system processes an average of 7 transactions per second, and the Ethereum system processes an average of 18 transactions per second), making it unable to carry Internet-level applications well. The throughput of the blockchain system is limited by network bandwidth (1), the CPU processing power of the node (2), and the read and write capabilities of the disk (3). After a node generates a block, it needs enough time for other nodes to synchronize the new block before generating the next block. Therefore, the network bandwidth will limit the propagation speed of the block, thereby reducing the performance of the blockchain.

[0068] In response to network bandwidth (1), various sharding schemes have been proposed in related technologies. For example, the block-producing nodes are divided into multiple smaller committees, each of which processes the received transactions in parallel, thus reducing the propagation range of the block and improving the throughput of the blockchain. However, this sharding scheme allocates a portion of the read and write permissions of the account status to each blockchain shard based on the smart contract account. It cannot effectively cope with phenomenal blockchain applications, such as Ethereum CryptoKitties. When the phenomenal blockchain application was born, a large number of users simultaneously initiated transactions to call its smart contract. Since they all changed the storage space of the same smart contract, these transactions were all allocated to the same blockchain shard, causing congestion in the blockchain system. In response to the CPU processing power of the node (2), the solution of related technologies is to execute transactions in parallel and ensure that the results of parallel execution are consistent with the results of serial execution. However, the parallel execution scheme requires the user to manually input the storage area that each function of the contract will access, and then execute transactions with mutually exclusive access areas in parallel, and execute transactions with overlapping access areas in serial. Relying on manual user input may introduce incorrect storage access location information, reduce CPU usage efficiency, and even cause serious problems such as inconsistency with serial execution of transactions.

[0069] To address the above issues, the data processing methods, devices, media, and program products provided in the embodiments of this application use each access area of ​​the storage space as a unit, assigning each access area to a corresponding blockchain shard. This application then analyzes which access areas in the storage space a transaction involves, allowing the transaction to be assigned to the corresponding blockchain shard for processing. This allows for large numbers of transactions that call the same smart contract to be distributed across different blockchain shards for processing, better supporting internet-level applications. By analyzing the access areas used by each function, the problem of manual user input is resolved, improving the readability and reliability of the contract parallelization solution.

[0070] The technical solution of the present application is described in detail below through specific embodiments. It should be noted that the following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments.

[0071] Figure 2 This is a flow chart of the data processing method provided in the embodiment of the present application, which can be applied to a blockchain platform with smart contract functions (such as Ethereum). Figure 2 As shown, the method may specifically include the following steps:

[0072] S201. Obtain the smart contract called by the user-initiated exchange and convert the smart contract into an operation code.

[0073] In this embodiment, the smart contract is usually in the form of machine code, which can only be recognized by computer devices. The operation code can be obtained by decompiling the smart contract, and the obtained operation code can be recognized by humans.

[0074] For example, taking the machine code "608060405234," we first break down the smart contract's machine code sequence into bytes: "60 80 60 40 52 34." Then, according to Appendix A of the Ethereum Yellow Paper, we decompile the machine code into opcodes. These opcodes might include "PUSH1 MSTORE CALLVALUE," and so on.

[0075] S202: Get the target operation code from the operation code.

[0076] The target operation code is an operation code used to access the storage space of the blockchain platform, and the storage space is divided into at least two access areas.

[0077] In this embodiment, illustratively, the target opcode may be any one of SSTORE and SLOAD. When these opcodes are executed, content will be written to or read from a specified area of ​​the storage space.

[0078] S203. Determine the target access area of ​​the function in the smart contract in the storage space according to the target opcode.

[0079] For example, the function in the smart contract may be a transfer function, that is, the user initiates a transfer transaction.

[0080] In this embodiment, when a user initiates a transaction to call a smart contract, the smart contract code will be loaded into the Ethereum virtual machine and run. When it encounters an opcode related to storage space access (the opcode is located in the function), the content will be written or read from the specified area of ​​the storage space based on the top element of the stack before the opcode is executed, that is, the target access area of ​​the function is obtained.

[0081] Each function may have a different target access area in the storage space. A large number of users may initiate transactions at the same time, all of which may call the same smart contract. However, because existing technologies assign read and write permissions for a portion of account status to each blockchain shard on a per-account basis, all transactions calling the same smart contract are assigned to the same blockchain shard for processing, causing congestion in the blockchain system.

[0082] For example, in this embodiment, in order to obtain the top element of the stack before the execution of the opcode related to storage space access before the smart contract runs, the smart contract can be decompiled to extract the stack status before the execution of the opcode related to storage space access, function boundaries, the loading location of function parameters and environment information, the information flow of various data and other derivation information, and then based on the extracted derivation information, it can be deduced whether the function has an access operation to the storage space and the source of information that determines its access area.

[0083] The decompilation process may include five steps: basic block partitioning, local stack analysis, control flow graph construction, function boundary deduction, and function parameter and return value deduction. Through these five steps, the above data information is extracted.

[0084] Specifically, basic block partitioning involves converting a smart contract in machine code into a sequence of basic blocks consisting of human-readable operations. Local stack analysis primarily analyzes the stack of each partitioned basic block, clarifying the stack contents before and after the Ethereum Virtual Machine executes each opcode. Control flow graph construction analyzes the relationships between basic blocks and connects them to determine the connections between them. Function boundary derivation derives function boundaries based on the control flow graph. Function parameter and return value derivation analyzes the parameters passed into a function and the function's return value.

[0085] S204. Determine the blockchain shard corresponding to the target access area according to the preset corresponding relationship.

[0086] Among them, the blockchain shard includes at least one node, and the preset corresponding relationship includes the blockchain shard corresponding to each access area.

[0087] Among them, nodes can be understood as computer devices. The sharding scheme in blockchain technology mainly divides the blockchain network into multiple fragments (i.e., multiple shards). Each fragment contains a certain number of nodes. These nodes process the transactions in each fragment separately to improve the performance of the entire blockchain system and increase throughput.

[0088] S205: Allocate the transaction to the blockchain shard for processing.

[0089] In this embodiment, each access area of ​​the storage space can be assigned to a corresponding blockchain shard. When a blockchain shard processes a transaction, it can write / read content in the corresponding access area. This allows for the diversion of a large number of transactions, determining which transaction is assigned to which blockchain shard for execution, rather than having all transactions processed by the same blockchain shard, thereby improving the throughput of the blockchain system.

[0090] In the embodiment of the present application, the storage space is divided into segments, and different access areas correspond to different blockchain shards. When a large number of transactions call the same smart contract at the same time, different blockchain shards can also be selected for processing based on their corresponding access areas, thereby improving the throughput of the blockchain system.

[0091] In some embodiments, the above step S203 may be further implemented by the following steps:

[0092] Get the element stored at the top of the execution stack before the target opcode;

[0093] Based on the element, determine the target access area of ​​the function in the storage space.

[0094] The target operation code is an operation code for accessing storage space. For example, the target operation code can be any one of SSTORE and SLOAD.

[0095] In this embodiment, the Ethereum Virtual Machine's stack state (e.g., the top element) may vary when executing each opcode. To statically analyze the contents of the top element before executing the target opcode without running the smart contract, the smart contract can be decompiled to obtain the top element. Specifically, this involves basic block partitioning, local stack analysis, and control flow graph construction. By constructing the control flow graph, the top element can be analyzed.

[0096] The embodiment of the present application analyzes the target access area of ​​the function in the smart contract without running the smart contract, which can better plan the execution plan of the transaction, determine which transaction is processed in which blockchain shard or which transactions can be executed in parallel, improve the throughput of the blockchain system, and enable the blockchain system to carry Internet-level applications.

[0097] Furthermore, in some embodiments, the value of the top element of the stack can be divided into two cases. One case is that the value of the top element of the stack can be known before the contract is run. In this case, the above step of "determining the target access area of ​​the function in the storage space based on the element" can be implemented by the following steps:

[0098] Determine whether the value of an element is a constant;

[0099] If the value of the element is a constant, the constant is used as the target access area of ​​the function in the storage space.

[0100] In this embodiment, after decompiling the smart contract, if the value of the top element of the stack is determined to be a constant, such as 0x1, then the function's target access area can be determined to correspond to slot 1 in the storage space, and the read / write operation is performed on slot 1. The storage space includes multiple slots, and each slot can be understood as an access area.

[0101] For example, after decompiling a smart contract and determining that the value of an element is a constant, the following two pieces of information can be derived based on the above-mentioned derivation information: the entry function signature (pubFunSign) and the storage space (Storage) read / write location (slotNum). These two pieces of information are derived based on the following facts in the derivation information: (1) there is a SLOAD or SSTORE opcode, which uses index as the key to access the storage space; (2) the value of the variable index is a constant (slotNum); and (3) the opcode is in the function (pubFunSign).

[0102] The SSTORE opcode uses the first element of the stack as the key and stores the contents of the second element in the stack into the storage space. The SLOAD opcode uses the first element of the stack as the key and loads the contents from the storage space to the top of the stack. Therefore, the access area of ​​the storage space is related to the key of the first element in the stack before the SSTORE opcode is executed, as well as the key of the first element in the stack before the SLOAD opcode is executed. Simply by obtaining the specific contents of the element, the access area of ​​the storage space can be determined.

[0103] The embodiment of the present application detects the value of the top element of the stack. If it is a constant, the target access area of ​​the function can be directly determined. The result can be obtained quickly and accurately to plan the execution plan of the transaction, determine which transaction is processed in which blockchain shard or which transactions can be executed in parallel, improve the throughput of the blockchain system, and enable the blockchain system to carry Internet-level applications.

[0104] Furthermore, in some embodiments, for another situation where the value of the top element of the stack is unknown before the contract is executed, it is necessary to trace the source of this value (i.e., the information flow) to determine whether it is an environment parameter or a function parameter. When the contract is executed, the specific target access area is determined based on the actual situation. The above-mentioned "determining the target access area of ​​the function in the storage space based on the element" can be implemented in the following steps:

[0105] Determine whether the value of the element is an environment parameter / function parameter;

[0106] If the value of the element is an environment parameter / function parameter, the derivation information of the target area is obtained;

[0107] The target access area is determined according to the deduction information, the first preset deduction rule corresponding to the environmental parameter / the second deduction rule corresponding to the function parameter.

[0108] The derivation information at least includes the stack state, function boundaries, function parameters, and the loading location and information flow of environment information before the target opcode is executed.

[0109] In this embodiment, after decompiling the smart contract, when it is determined that the value of an element is an environment parameter or a function parameter, it is necessary to further deduce and determine the target access area based on the preset deduction rules and the deduction information obtained during the decompilation process.

[0110] When the value of the top element of the stack is an environmental parameter, the target access area is determined based on a first preset derivation rule corresponding to the derivation information and the environmental parameter. When the value of the top element of the stack is a function parameter, the target access area is determined based on a second preset derivation rule corresponding to the derivation information and the function parameter. The preset derivation rule derives the target access area based on facts in the derivation information.

[0111] In some implementations, obtaining the element stored at the top of the stack may be achieved by the following steps:

[0112] Obtaining the position and opcode parameters of each opcode, and combining each opcode, the position and the opcode parameters to obtain an opcode sequence;

[0113] Divide each opcode sequence into blocks and determine the basic block in which each opcode sequence is located;

[0114] Perform stack analysis on each basic block to determine the elements in the stack before and after each opcode is executed;

[0115] Determine the connection relationship between each basic block and construct a control flow graph;

[0116] According to the control flow graph, get the element stored at the top of the stack before the target opcode is executed.

[0117] In this embodiment, in the basic block division of the decompilation process, the machine code sequence of the smart contract is first divided into bytes, for example, the machine code sequence of "608060405234" is divided into "60 80 60 40 52 34". Then, according to Appendix A of the existing Ethereum Yellow Paper, the machine code is translated into an opcode. To facilitate subsequent analysis, it is necessary to supplement the position information for each opcode (i.e., the byte at which it is located), and finally form a triple sequence (i.e., opcode position, opcode, opcode parameter). Among them, not all opcodes have parameters. If the opcode has no parameters, the corresponding opcode parameter is empty, such as converting "60 80 60 40 52 34" into four triplets "(0x0, PUSH1, 0x80), (0x2, PUSH1, 0x40), (0x4, MSTORE), (0x5, CALLVALUE,)". Finally, traverse the opcodes and divide the opcode sequence into basic block sequences.

[0118] Figure 3 The basic block division diagram provided in the embodiment of the present application is as follows: Figure 3 When the traversal reaches the jump position opcode (JUMPDEST), the current basic block ends and the opcode becomes the first opcode of the new basic block; when the traversal reaches the jump opcode (JUMP, JUMPI) or stop opcode (STOP, RETURN, SELFDESTRUCT, REVERT), the opcode becomes the last opcode of the current basic block.

[0119] During the basic block division process, six pieces of information can be analyzed using smart contract decompilation tools: StatementNext, StatementOpcode, PushValue, BlockHead, BlockTail, and StatementBlock. StatementNext indicates the location of the next opcode of the opcode located at stmt (stmtNext); StatementOpcode indicates the opcode op located at stmt; PushValue indicates the opcode parameter val located at stmt, meaning that this opcode pushes val onto the top of the stack; BlockHead indicates that the first opcode of the basic block block (the position of the basic block is identified by the position of the first opcode of the basic block) is the opcode located at stmt; BlockTail indicates that the last opcode of the basic block block is the opcode located at stmt; and StatementBlock indicates that the opcode located at stmt belongs to the basic block block. StatementOpcode will be used to deduce the Storage access area.

[0120] During the local stack analysis process of the decompilation process, smart contract decompilation tools can analyze and obtain three pieces of information: StatementDefines, LocalStackContents, and VariableValue. StatementDefines indicates that the variable var is defined at the stmt position. This actually pushes var to the top of the stack when the opcode at the stmt position is executed. This variable representation facilitates subsequent information flow analysis, allowing for tracking the final destination of the pushed value. LocalStackContents indicates the variable var stored at each index in the stack after the stmt opcode is executed. VariableValue indicates the value of the variable var is val. Using the StatementOpcode obtained in the previous step and the StatementDefines obtained in this step, the opcode location and value of the loading environment information can be deduced: CALLER(stmt, to), ORIGIN(stmt, to), ADDRESS(stmt, to), TIMESTAMP(stmt, to), and NUMBER(stmt, to). This information is used to derive the Storage access area. VariableValue is also used in the Storage access area derivation.

[0121] During the construction of the control flow graph (CFG) in the decompilation process, the basic block segmentation step reveals that the last opcode of a basic block can be of three types: jump, stop, and other. For jump opcodes, the stack context before the jump opcode is obtained based on the results of local stack analysis to determine the jump target. For stop opcodes, no analysis is required. For other opcodes, the basic block is directly connected to the basic block containing the next opcode following the last opcode of the basic block. This completes the construction of the control flow graph. From this process, five pieces of information can be obtained through analysis using smart contract decompilation tools: BlockOutputContents, BlockInputContents, BlockJumpTarget, BlockEdge, and StatementUses. Among them, BlockOutputContents represents the variable var stored at each index in the stack after executing the basic block block; BlockInputContents represents the variable var stored at each index in the stack before executing the basic block block; BlockJumpTarget indicates that the jump target of the basic block block is the value of the variable var; BlockEdge indicates that the basic block caller is connected to the basic block callee; StatementUses indicates that the value of the variable var stored at the index-th element of the stack is used when executing the opcode located at stmt. Using the StatementOpcode and StatementDefines obtained in the previous step and the StatementUses obtained in this step, the relevant information of the Storage access opcode StorageAccessStmt(slotNum, to), SLOAD(stmt, index), and SSTORE(stmt, index) can be derived. This information is used to derive the subsequent Storage access area.

[0122] After constructing the control flow graph, in some embodiments, the boundaries of the functions in the smart contract can be obtained based on the control flow graph, and based on the boundaries of the function, it can be determined whether the function contains the target opcode.

[0123] The boundary includes the entry position and the end position of the function.

[0124] Specifically, during the decompilation process, the function boundary derivation process first uses the function selector information in the contract code to obtain the entry point of each function, and then relies on the control flow graph to deduce the end position of the function. In this process, two pieces of information, PublicFunctionSelector and InPublicFunction, can be analyzed through smart contract decompilation tools (such as gigahorse). PublicFunctionSelector indicates that the signature of the function pubFun is pubFunSign; InPublicFunction indicates that the opcode located in stmt is in a function with the function signature pubFunSign. Both pieces of information are used to deduce the Storage access area.

[0125] During the decompilation process of function parameters and return values, the function parameter information PublicFunctionArg can be obtained through analysis of the smart contract decompilation tool. PublicFunctionArg indicates that the argIndex-th parameter of the function pubFun is the variable arg.

[0126] Figure 4 This is a schematic diagram of the derivation information output by the smart contract decompilation provided in the embodiment of this application, such as Figure 4 As shown, the derivation information specifically includes the following information: StatementNext, StatementOpcode, PushValue, BlockHead, BlockTail, StatementBlock, StatementDefines, LocalStackContents, VariableValue, BlockOutputContents, BlockInputContents, BlockJumpTarget, BlockEdge, StatementUses, PublicFunctionSelector, InPublicFunction, and PublicFunctionArg.

[0127] Among them, S is the set of statement identifiers (S∈Z), C is the set of constants (C∈Z), B is the set of basic block identifiers, I is the set of stack numbers, O is the set of opcodes, V is the set of variables, and F is the set of functions.

[0128] Furthermore, in some embodiments, when the value of the element is an environmental parameter, the target access area can be derived and determined by the following steps:

[0129] Determine, based on the derivation information, whether the function signature of the function contains an identification operation code and whether the identification operation code is an operation code for obtaining environment parameters;

[0130] If the function includes an identification operation code and the identification operation code is an operation code for obtaining environment parameters, the target access area is determined according to the environment parameters.

[0131] In this embodiment, according to the Ethereum Yellow Paper, the opcodes involved in storage access are SSTORE and SLOAD. The SSTORE opcode uses the first element in the stack as the key and stores the contents of the second element in the stack into the smart contract's Storage. The SLOAD opcode uses the first element in the stack as the key and loads the contents from Storage to the top of the stack. Therefore, the target access area is related to the first element in the stack before the SSTORE opcode is executed, as well as the first element in the stack before the SLOAD opcode is executed. Simply obtaining the specific contents of these elements can determine the target access area.

[0132] The specific content of the element may be determined when the contract is running. For example, the element is defined when executing opcodes such as CALLDATALOAD or CALLER to obtain environmental information. The value of the variable is the value pushed into the stack when executing these opcodes. These values ​​can only be confirmed at runtime.

[0133] Among them, when the element is an environment parameter (that is, defined when executing the operation code related to obtaining environment information), it is possible to first determine whether the smart contract contains an identification operation code stmt and the identification operation code stmt is an operation code for obtaining environment parameters (for example, these operation codes can be CALLER / ORIGIN / ADDRESS / TIMESTAMP / NUMBER). If these operation codes are operation codes for obtaining environment parameters, and the environment parameters obtained by the identification operation code stmt are used as the above-mentioned key, and the identification operation code stmt is in the specified function (pubFunSign) obtained by the above-mentioned derivation information, then three pieces of information can be determined, namely the entry function signature (pubFunSign), the environment information type (op) that determines the read and write offset position, and the read and write starting position (slotNum). These three pieces of information represent the target access area.

[0134] The embodiment of the present application derives the access area determined by environmental parameters and allocates corresponding blockchain shards based on the access area, so that the sharding scheme of the blockchain solution can be made more granular, and the blockchain system does not experience transaction congestion when carrying phenomenal blockchain applications.

[0135] In some embodiments, when the value of an element is a function parameter, the target access area can be determined by deducing the following steps:

[0136] Based on the derivation information, determine whether the function signature of the function meets the preset conditions and whether the function parameters have been loaded at the preset position;

[0137] If the function signature of the function meets the preset conditions and the function parameters have been loaded at the preset location, the target access area is determined based on the function parameters.

[0138] In this embodiment, when the element is a function parameter, we first determine whether there is an entry point function (pubFun) with the signature (pubFunSign) and that the entry point function (pubFun) loads a function parameter (arg) from the argIndex position, and the function parameter (arg) is used as the key. If so, we can determine the following three pieces of information: the entry point function signature (pubFunSign), the function parameter position (argIndex) that determines the read and write offset position, and the read and write starting position (slotNum).

[0139] The embodiment of the present application derives the access area determined by the function parameters and allocates the corresponding blockchain shards based on the access area, which can make the sharding scheme of the blockchain solution more granular. When a large number of transactions call the same smart contract at the same time, different blockchain shards can be selected for processing based on their corresponding access areas, thereby improving the throughput of the blockchain system and preventing transaction congestion when the blockchain system carries phenomenal blockchain applications.

[0140] Figure 5 A schematic diagram of the derivation rules provided in the embodiment of the present application is shown in FIG. Figure 5 As shown, Figure 5 Above the figure is the declaration of the derivation rule, specifically EnvConflict(pubFunSign: FS, OP: O, slotNum: SN); FunArgConflict(pubFunSign: FS, argindex: I, slotNum: SN); ConsConflict(pubFunSign: FS, slotNum: SN). Below the figure is the specific content of the derivation rule.

[0141] Among them, the first deduction rule is EnvConflict, which is used to deduce the Storage access area determined by the environment information. This deduction rule derives three pieces of information: the entry function signature (pubFunSign), the environment information type (op) that determines the read and write offset position, and the read and write starting position (slotNum). These three pieces of information are derived from the following four facts: (1) The smart contract contains an opcode (stmt); (2) The opcode (stmt) is CALLER / ORIGIN / ADDRESS / TIMESTAMP / NUMBER, which is used to obtain environment information (to); (2) The content obtained by the opcode (to) is used as the key for accessing the storage space; (3) The opcode (stmt) is in the specified function (pubFunSign).

[0142] The second inference rule, FunArgConflict, is used to infer the storage space access area determined by function parameters. This inference rule infers three pieces of information: the entry function signature (pubFunSign), the function parameter position (argIndex) that determines the read and write offsets, and the read and write starting position (slotNum). These three pieces of information are inferred from the following three facts: (1) There is an entry function (pubFun) with the signature (pubFunSign); (2) The function (pubFun) loads a function parameter (arg) from the argIndex position; and (3) The function parameter (arg) is used as a key to access the storage space.

[0143] The third inference rule, ConsConflict, is used to infer storage access areas known before contract deployment. This inference rule infers two pieces of information: the entry function signature (pubFunSign) and the storage read / write location (slotNum). These three pieces of information are inferred from the following three facts: (1) the existence of a SLOAD or SSTORE opcode (stmt), which uses index as the key for storage access; (2) the value of the variable index is a constant (slotNum); and (3) the opcode (stmt) is inside the function (pubFunSign).

[0144] In some embodiments, the above method may further include the following steps:

[0145] Get transactions assigned to the same blockchain shard and transactions assigned to different blockchain shards;

[0146] Control the serial processing of transactions assigned to the same blockchain shard;

[0147] Controls parallel processing of transactions assigned to different blockchain shards.

[0148] In this embodiment, transactions with mutually exclusive access regions (i.e., transactions assigned to different blockchain shards) can be executed in parallel, while transactions with overlapping access regions (i.e., transactions assigned to the same blockchain shard) can be executed serially. When two users simultaneously call a smart contract function, if the target access regions corresponding to the functions they call are different, the two users' calls can be executed in parallel, processing transactions initiated by both users simultaneously, thereby improving the throughput of the blockchain system. Furthermore, this embodiment automatically controls the parallel execution of transactions with mutually exclusive access regions and the serial execution of transactions with overlapping access regions, eliminating the need for users to manually enter the access region for each function, thus avoiding manual input errors and ensuring the reliability of parallel transaction execution.

[0149] In some embodiments, the above method may further include the following steps:

[0150] Get the first transaction and the second transaction;

[0151] The first transaction and the second transaction are read and written uniformly.

[0152] The smart contracts invoked by the first and second transactions access the same storage area within the blockchain platform. In this embodiment, access area analysis can be used to identify transactions that modify the same access area, and the multiple disk reads and writes triggered by these transactions can be optimized into a single disk read and write. This improves disk read and write efficiency and increases the throughput of the blockchain system.

[0153] For example, let’s take the transfer function “transfer” in a common smart contract as an example:

[0154]

[0155] It includes three storage space accesses: ① The third line of the contract snippet reads the balance of the contract caller (msg.sender) and compares it with the second function parameter "_value". "Balances" is stored in the storage space, and the contract caller (msg.sender) determines the storage space access area; ② The fourth line of the contract snippet, compared to the storage access in the third line of the contract snippet, not only reads the balance of the contract caller (msg.sender), but also updates its balance; ③ The fifth line of the contract snippet reads and updates the "balances" of "_to". The value of "_to" comes from the first parameter of the function. In other words, the first parameter of the function determines the storage space access area.

[0156] By applying the method proposed in this solution, the Storage access area of ​​the contract fragment can be automatically analyzed. The analysis results are shown in Table 1 below:

[0157]

[0158] Table 1

[0159] The "transfer" function has two storage space access conflicts related to environment information (EnvConflict) and one storage space access conflict related to function parameters (FunArgConflict). "0xa9059cbb" in "EnvConflict" represents the function signature of the "transfer" function; "CALLER" and "0x1" in "EnvConflict" indicate that the function will access the area of ​​the contract storage space associated with the contract caller address and "0x1"; "0xa9059cbb" in "FunArgConflict" is also the function signature of the "transfer" function; "0" and "0x1" in "FunArgConflict" indicate that the function will access the area of ​​the contract storage space associated with the first function parameter and "0x1". Therefore, it can be concluded that the "transfer" function has two storage space access areas: one determined by the contract caller address and "0x1", and the other determined by the function's first parameter and "0x1".

[0160] If two users call a contract's "transfer" function simultaneously, passing different first parameters, the two contract calls can execute in parallel. However, according to existing contract parallel execution schemes, these two calls can only execute serially. This is because these schemes determine that the storage space accessed by these two contract calls is the entire contract's storage space, and the access areas overlap, so they can only execute serially.

[0161] The following are device embodiments of the present application, which can be used to implement the method embodiments of the present application. For details not disclosed in the device embodiments of the present application, please refer to the method embodiments of the present application.

[0162] Figure 6 This is a structural diagram of a data processing device provided in an embodiment of the present application. The data processing device can be integrated on a blockchain platform (such as Ethereum). Figure 6 As shown, the data processing device 60 may specifically include an operation code conversion module 61, an operation code acquisition module 62, a region acquisition module 63, a shard determination module 64, and a transaction allocation module 65.

[0163] The opcode conversion module 61 is used to obtain the smart contract invoked by the user-initiated transaction and convert the smart contract into an opcode. The opcode acquisition module 62 is used to obtain the target opcode from the opcode. The region acquisition module 63 is used to determine the target access region in the storage space for the function in the smart contract based on the target opcode. The shard determination module 62 is used to determine the blockchain shard corresponding to the target access region based on a preset correspondence. The transaction allocation module 63 is used to allocate the transaction to the blockchain shard for processing.

[0164] Among them, the target operation code is an operation code used to access the storage space of the blockchain platform, the storage space is divided into at least two access areas, the blockchain shard includes at least one node, and the preset correspondence relationship includes the blockchain shard corresponding to each access area.

[0165] In some embodiments, the region acquisition module may be specifically used to:

[0166] Get the element stored at the top of the stack before the target opcode is executed;

[0167] Based on the element, determine the target access area of ​​the function in the storage space.

[0168] Optionally, in some embodiments, the block acquisition module may be specifically used to:

[0169] Determine whether the value of an element is a constant;

[0170] If the value of the element is a constant, the constant is used as the target access area of ​​the function in the storage space.

[0171] Optionally, in some embodiments, the block acquisition module may be specifically used to:

[0172] Determine whether the value of the element is an environment parameter / function parameter;

[0173] If the value of the element is an environment parameter / function parameter, the derivation information of the target area is obtained;

[0174] The target access area is determined according to the deduction information, the first preset deduction rule corresponding to the environmental parameter / the second preset deduction rule corresponding to the function parameter.

[0175] The derivation information is obtained by decompiling the smart contract, and the derivation information includes at least one of the stack state, function boundaries, function parameters, and loading location and information flow of environment information before the execution of the target opcode.

[0176] Optionally, in some embodiments, if the element is an environmental parameter, the block acquisition module may be specifically used to:

[0177] Determine, based on the derivation information, whether the function signature of the function contains an identification operation code and whether the identification operation code is an operation code for obtaining environment parameters;

[0178] If the function includes an identification operation code and the identification operation code is an operation code for obtaining environment parameters, the target access area is determined according to the environment parameters.

[0179] Optionally, in some embodiments, if the above elements are function parameters, the above block acquisition module may be specifically used to:

[0180] Based on the derivation information, determine whether the function signature of the function meets the preset conditions and whether the function parameters have been loaded at the preset position;

[0181] If the function signature of the function meets the preset conditions and the function parameters have been loaded at the preset location, the target access area is determined based on the function parameters.

[0182] Optionally, in some embodiments, the block acquisition module may be specifically used to:

[0183] Obtaining the position and opcode parameters of each opcode, and combining each opcode, the position and the opcode parameters to obtain an opcode sequence;

[0184] Divide each opcode sequence into blocks and determine the basic block in which each opcode sequence is located;

[0185] Perform stack analysis on each basic block to determine the elements in the stack before and after each opcode is executed;

[0186] Determine the connection relationship between each basic block and construct a control flow graph;

[0187] According to the control flow graph, get the element stored at the top of the stack before the target opcode is executed.

[0188] In some embodiments, the data processing apparatus further includes an operation code determination module configured to:

[0189] According to the control flow graph, obtain the boundaries of the functions in the smart contract, including the entry and end positions of the functions;

[0190] Based on the function's boundaries, determine whether the function contains the target opcode.

[0191] In some embodiments, the data processing device further includes a read / write processing module configured to:

[0192] Get the first transaction and the second transaction;

[0193] The first transaction and the second transaction are read and written uniformly.

[0194] The smart contracts called by the first transaction and the second transaction have the same access area in the storage space of the blockchain platform.

[0195] The device provided in the embodiments of the present application can be used to execute the method in the above embodiments. Its implementation principle and technical effects are similar and will not be repeated here.

[0196] It should be noted that the division of the various modules of the above device is merely a division of logical functions. In actual implementation, they can be fully or partially integrated into a single physical entity or physically separated. Furthermore, these modules can be implemented entirely in software called by a processing element, or entirely in hardware. Alternatively, some modules can be implemented in software called by a processing element, while others can be implemented in hardware. For example, the block acquisition module can be a separate processing element, or it can be integrated into a chip of the above device. Furthermore, it can be stored in the memory of the above device in the form of program code, which can be called and executed by a processing element of the device. The implementation of other modules is similar. Furthermore, these modules can be fully or partially integrated or implemented independently. The processing element here can be an integrated circuit with signal processing capabilities. During implementation, the steps of the above method or the above modules can be performed by hardware integrated logic circuits in the processor element or by software instructions.

[0197] Figure 7 This is a schematic diagram of the structure of the computer device provided in the embodiment of the present application. Figure 7 As shown, the computer device 70 includes at least one processor 71 , a memory 72 , a bus 73 and a communication interface 74 .

[0198] The processor 71 , the communication interface 74 and the memory 72 communicate with each other via the bus 73 .

[0199] The communication interface 74 is used to communicate with other devices. The communication interface 74 includes a communication interface for data transmission and a display interface or operation interface for human-computer interaction.

[0200] The processor 71 is configured to execute computer instructions stored in the memory 72, and specifically to execute the relevant steps of the method described in the above embodiment. Specifically, the program may include program code, which includes computer operation instructions.

[0201] The processor may be a central processing unit. The one or more processors included in the computer device may be processors of the same type, such as one or more CPUs; or they may be processors of different types, such as one or more CPUs and one or more ASICs.

[0202] Memory is used to store computer instructions. The memory may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage.

[0203] This embodiment further provides a readable storage medium, in which computer instructions are stored. When at least one processor of a computer device executes the computer instructions, the computer device executes the data processing methods provided in the various embodiments described above.

[0204] This embodiment further provides a program product, comprising computer instructions stored in a readable storage medium. At least one processor of a computer device can read the computer instructions from the readable storage medium, and at least one processor can execute the computer instructions to cause the computer device to implement the data processing methods provided in the various embodiments described above.

[0205] In this application, "at least one" means one or more, and "more" means two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can mean: the existence of A alone, the existence of A and B at the same time, and the existence of B alone, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship; in the formula, the character " / " indicates that the previous and next associated objects are in a "division" relationship. "At least one of the following items" or similar expressions refers to any combination of these items, including any combination of single items or plural items. For example, at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, c can be single or multiple.

[0206] It is understood that the various numerical numbers involved in the embodiments of the present application are only for the convenience of description and are not intended to limit the scope of the embodiments of the present application. In the embodiments of the present application, the order of the sequence numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0207] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some or all of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A data processing method, characterized in that: Applied to a blockchain platform with smart contract functionality, the method includes: Obtain the smart contract invoked by the user-initiated exchange and convert the smart contract into an opcode; Obtaining a target opcode from the opcode, where the target opcode is an opcode for accessing a storage space of the blockchain platform, where the storage space is divided into at least two access areas; Determine, according to the target opcode, a target access area of ​​the function in the smart contract in the storage space; Determine, based on a preset correspondence, a blockchain shard corresponding to the target access area, wherein the blockchain shard includes at least one node, and the preset correspondence includes a blockchain shard corresponding to each access area; The transaction is assigned to the blockchain shard for processing.

2. The method according to claim 1, characterized in that Determining, according to the target operation code, a target access area of ​​the function in the smart contract in the storage space of the blockchain platform includes: Obtain the element stored at the top of the stack before the target opcode is executed; A target access area of ​​the function in the storage space is determined according to the element.

3. The method according to claim 2, characterized in that The determining, based on the element, a target access area of ​​the function in the storage space includes: Determining whether the value of the element is a constant; If the value of the element is a constant, the constant is used as the target access area of ​​the function in the storage space.

4. The method according to claim 2, characterized in that The determining, based on the element, a target access area of ​​the function in the storage space includes: Determine whether the value of the element is an environment parameter / function parameter; If the value of the element is the environment parameter / function parameter, obtaining derivation information of the target access area, where the derivation information is obtained by decompiling the smart contract, and the derivation information includes at least one of the stack state, function boundaries, function parameters, and the loading location and information flow of environment information before the execution of the target opcode; The target access area is determined according to the deduction information, the first preset deduction rule corresponding to the environmental parameter / the second preset deduction rule corresponding to the function parameter.

5. The method according to claim 4, characterized in that If the element is the environmental parameter, determining the target access area according to the derivation information and a first preset derivation rule corresponding to the environmental parameter includes: Determining, based on the derivation information, whether a function signature of the function includes an identification operation code and the identification operation code is an operation code for obtaining environment parameters; If the function includes the identification operation code and the identification operation code is an operation code for obtaining the environment parameter, the target access area is determined according to the environment parameter.

6. The method according to claim 4, characterized in that If the element is a function parameter, determining the target access area according to the derivation information and a second preset derivation rule corresponding to the function parameter includes: Determining, based on the derivation information, whether the function signature of the function satisfies a preset condition and whether the function parameters have been loaded at a preset location; If the function signature of the function meets a preset condition and the function parameters have been loaded at a preset position, the target access area is determined according to the function parameters.

7. The method according to claim 2, characterized in that The obtaining of the element stored at the top of the stack before the target opcode is executed includes: Obtaining the position and opcode parameters of each opcode, and combining each opcode, the position and the opcode parameters to obtain an opcode sequence; Divide each opcode sequence into blocks and determine the basic block in which each opcode sequence is located; Perform stack analysis on each basic block to determine the elements in the stack before and after each opcode is executed; Determine the connection relationship between each basic block and construct a control flow graph; According to the control flow graph, the element stored at the top of the stack before the target opcode is executed is obtained.

8. The method according to claim 7, characterized in that The method further comprises: Obtaining, according to the control flow graph, a boundary of the function in the smart contract, wherein the boundary includes an entry position and an end position of the function; According to the boundary of the function, it is determined whether the function contains the target operation code.

9. The method according to claim 1, characterized in that The method further comprises: Get transactions assigned to the same blockchain shard and transactions assigned to different blockchain shards; Control the serial processing of transactions assigned to the same blockchain shard; Controls parallel processing of transactions assigned to different blockchain shards.

10. The method according to claim 1, characterized in that The method further comprises: Obtaining a first transaction and a second transaction, where the smart contracts invoked by the first transaction and the second transaction have the same access area in the storage space of the blockchain platform; The first transaction and the second transaction are read and written uniformly.

11. A computer device, characterized in that: include: a processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the method according to any one of claims 1 to 10.

12. A readable storage medium, characterized in that: The readable storage medium stores computer instructions, which are used to implement the method according to any one of claims 1 to 10 when executed by a processor.

13. A program product comprising computer instructions, characterized in that When the computer instructions are executed by a processor, the method according to any one of claims 1 to 10 is implemented.

Images