Method for managing block chain data of multiple virtual machines through unified MPT

Abstract

The invention discloses a method for managing multi-virtual-machine block chain data through a unified MPT, the unified MPT stores state values corresponding to different virtual machines by defining different prefix indexes, the different virtual machines have independent account book state spaces, the MPT provides a unified interface, any type of keys can be stored, and the management efficiency is improved. A plurality of virtual machines use the same underlying data structure for storage, and the method comprises the steps that an execution engine judges the format of a transaction; when the format of the transaction corresponds to the first virtual machine, sending the transaction to the first virtual machine for execution; when the format of the transaction corresponds to the second virtual machine, the transaction is sent to the second virtual machine to be executed; and after the transaction is executed, a transaction execution result is stored in the unified MPT. According to the invention, the efficiency and security of data management can be improved, the data redundancy is reduced, the interoperability and expansibility of the system are enhanced, and the learning and maintenance costs of developers are reduced.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and in particular to a method for managing multi-virtual machine blockchain data through a unified MPT. Background Art

[0002] Most existing blockchain systems only support a single type of virtual machine (VM). For example, the Ethereum blockchain mainly supports the Ethereum virtual machine (EVM), while the Aptos blockchain only supports the Move virtual machine (MoveVM).

[0003] Since each blockchain platform usually only supports a specific virtual machine, smart contracts can only run on a specific blockchain.

[0004] Among them, EVM is a stack-based virtual machine designed to execute Ethereum smart contracts and supports smart contracts written in Solidity language. Smart contracts are first compiled into bytecodes and then executed by EVM on each node of the blockchain network. The original intention of EVM design is to provide a reliable execution platform in a decentralized environment, ensuring that smart contracts can run automatically without trusting any centralized entity, thereby realizing an automated trust mechanism. This model has greatly promoted the development of decentralized applications (DApps) and brought a wide range of application scenarios to the Ethereum ecosystem.

[0005] Move VM was originally designed for Facebook's (now renamed Meta) Libra project and is now used in the Aptos blockchain to support smart contracts written in the Move language. The Move language provides a unique resource management model that focuses on security and flexibility. The Move virtual machine uses this model to prevent common security vulnerabilities in smart contracts, such as reentrancy attacks and integer overflows, thereby providing users with a more secure and reliable smart contract execution environment, ensuring that assets and smart contracts can be managed in a secure manner.

[0006] In the existing blockchain technology field, running multiple virtual machines on the same blockchain platform faces a series of challenges in data management. In traditional practices, in order to facilitate implementation and simplify management, each VM usually maintains its own independent state data storage, such as using its own MPT (Merkle Patricia Tree), that is, each uses a separate MPT to manage the ledger state, such as Move VM and EVM each have an MPT, that is, there are two MPTs.

[0007] In terms of interoperability, existing blockchain systems usually rely on specific middleware or communication protocols to achieve data exchange and communication between different virtual machines. Figure 1 As shown in the figure, blockchain network A represents a blockchain network, such as Ethereum, which uses EVM to execute smart contracts. Blockchain network B represents another blockchain network, such as Aptos, which uses Move VM to execute smart contracts. Middleware / Gateway: In order to achieve interoperability between two different blockchain networks, middleware or gateways need to be introduced. These middlewares act as bridges between different blockchain networks and are responsible for protocol conversion and packet forwarding.

[0008] Although EVM and Move VM play a vital role in their respective blockchain platforms, they also face several challenges: Insufficient interoperability: Since different blockchain platforms use different virtual machines and programming languages, this limits the interoperability of smart contracts between different platforms. There is a lack of a unified data management strategy, and the interoperability and data consistency between different virtual machines are difficult to be effectively guaranteed. For example, Ethereum's EVM and Aptos' Move VM cannot directly communicate or share data, which limits the development of cross-chain applications.

[0009] Decentralized data management: The current VMs all manage the ledger status through a separate MPT. When the number is small, the efficiency difference is not noticeable. If there are 20 virtual machines (VMs) in the same blockchain, managing 20 Merkle prefix trees (MPTs) will become more complicated and will lead to repeated and redundant maintenance work. Therefore, each virtual machine maintains its own independent state data storage, resulting in decentralized data management, increased data redundancy and maintenance costs, and synchronization delay problems.

[0010] Performance bottleneck: As the scale of blockchain networks expands, a single virtual machine may encounter performance bottlenecks, especially when processing a large number of transactions and smart contract calls. This fragmented data management method has become increasingly prominent in terms of performance bottlenecks when processing high-concurrency transactions and smart contract calls.

[0011] High development and maintenance costs: Each platform requires specific development tools and environments, and developers need to learn different technologies for each platform, which increases the learning cost and maintenance difficulty of developers. Finally, the complexity of smart contracts also poses challenges to security. Although Move VM and EVM have taken various measures to enhance security, there are still potential security risks.

[0012] Heavy burden on users: When users transfer assets between different blockchain platforms, they often need to rely on third-party services or complex cross-chain protocols, which is not only cumbersome to operate but may also bring security risks.

[0013] Using middleware or communication protocols to implement data exchange and communication between different virtual machines, although it has achieved cross-virtual machine interaction to a certain extent, it also increases the complexity of the system and potential performance overhead. The introduction of middleware may not only become a new failure point, but also introduce additional security risks.

[0014] In addition, security and data isolation are also key issues in the prior art. In an environment where multiple virtual machines coexist, how to ensure the data security and isolation of each virtual machine and prevent potential data leakage and unauthorized access is an urgent problem to be solved.

[0015] In summary, the existing multi-virtual machine blockchain data management method cannot meet actual usage needs. Summary of the invention

[0016] The embodiment of the present invention provides a method for managing multi-virtual machine blockchain data through a unified MPT, which solves the problem that the existing multi-virtual machine blockchain data management method cannot meet actual usage requirements.

[0017] The embodiment of the present invention provides a method for managing multi-virtual machine blockchain data through a unified MPT. The unified MPT stores state values ​​corresponding to different virtual machines by defining different prefix indexes. Different virtual machines have independent account state spaces. The MPT provides a unified interface that can store any type of key. Multiple virtual machines use the same underlying data structure for storage, including: an execution engine determines the format of a transaction; when the format of the transaction corresponds to a first virtual machine, the transaction is sent to the first virtual machine for execution; and when the format of the transaction corresponds to a second virtual machine, the transaction is sent to the second virtual machine for execution; after the transaction is executed, the transaction execution result is stored in the unified MPT.

[0018] Optionally, the unified MPT stores status values ​​corresponding to different virtual machines by defining different prefix indexes, specifically: the unified MPT stores status values ​​corresponding to the first virtual machine by defining a first prefix index; the unified MPT stores status values ​​corresponding to the second virtual machine by defining a second prefix index.

[0019] Optionally, the first prefix index is x.

[0020] Optionally, the second prefix index is y.

[0021] Optionally, the first virtual machine and the second virtual machine are different.

[0022] Optionally, before the execution engine determines the format of the transaction, the method further includes: receiving a transaction request; and parsing the format of the transaction.

[0023] Optionally, the parsing of the transaction format specifically includes: analyzing transaction data; and determining the transaction structure and type.

[0024] Optionally, before storing the transaction execution result in the unified MPT, the method further includes: judging the transaction execution result.

[0025] Optionally, after determining the transaction execution result, the method further includes: when the transaction execution is successful, executing the step of storing the transaction execution result in a unified MPT.

[0026] Optionally, after determining whether the transaction is successfully executed, the method further includes: when the transaction fails to execute, waiting for re-execution or discarding the transaction.

[0027] One or more technical solutions provided in the embodiments of the present invention have at least the following technical effects or advantages: The present invention manages multi-virtual machine blockchain data through a unified MPT. This method aims to improve the efficiency and security of data management and reduce data redundancy. At the same time, a single blockchain system can efficiently run multiple different virtual machines at the same time, such as Move VM and Ethereum VM, enhance the interoperability and scalability of the system, allow different virtual machines to exchange data and work together on the same blockchain platform, achieve seamless interoperability between different virtual machines, and support interaction with decentralized applications (DApps) running on different virtual machines without switching between multiple platforms, thereby significantly improving the user experience and providing new possibilities for the development and application of blockchain technology. The present invention reduces the learning and maintenance costs of developers by providing a unified data management and interaction interface. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 1 This is a diagram of the middleware interoperability model in the traditional blockchain system; Figure 2 This is a schematic diagram of the structure of the traditional Ethereum MPT; Figure 3 A schematic diagram of storage and indexing of different VM states of MPT in one embodiment of the present invention; Figure 4 Schematic diagram of the account book perspective of different VM spaces in one embodiment of the present invention; Figure 5 The present invention is a flowchart of a method for managing multi-virtual machine blockchain data through a unified MPT in one embodiment of the present invention. DETAILED DESCRIPTION

[0029] The embodiment of the present invention provides a method for managing multi-virtual machine blockchain data through a unified MPT, which solves the problem that the existing multi-virtual machine blockchain data management method cannot meet actual usage requirements.

[0030] In order to better understand the above-mentioned method of managing multi-virtual machine blockchain data through a unified MPT, the following will be described in detail in conjunction with the drawings and specific implementation methods of the specification. Obviously, the embodiments described in the present invention are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0031] like Figure 2 As shown, the structure of the traditional Ethereum MPT is as follows: 1. Root Hash: The root hash value generated by the KECCAK256 hash function. This is similar to the "Top Hash" of the Merkle tree and is used to ensure the integrity of the entire tree.

[0032] 2. World State Trie: Ethereum’s world state is stored in the form of key-value pairs, where the key is the account address and the value is the state of the corresponding account (such as balance). These key-value pairs are organized and compressed in the MPT tree structure.

[0033] 3. Extension Node: Next, you will see the green "Extension Node" with a shared prefix index of a7. These shared prefix indexes (shared nibble(s)) represent a number of common hexadecimal characters. Extension nodes are used to optimize storage by compressing the shared prefix index into one node to reduce storage redundancy.

[0034] 4. Branch Node: The blue branch node is used to store a series of paths starting from the root node. In this node, each child node corresponds to a hexadecimal character (such as 0 to f). The branch node contains 16 possible child nodes, and each child node can point to the next level node. Each branch node can store data values ​​(such as balance, etc.), and this node stores complete path information.

[0035] 5. Leaf Node: The purple leaf node is located at the bottom of the tree and is used to store actual data. Figure 2 In the tree, the leaf nodes store specific account status (such as balance 45.0 ETH, 1.1 ETH, etc.). The leaf nodes also compress the paths to ensure that the data is stored efficiently in the tree.

[0036] 6. Prefix index definition: Explanation of prefix index, including: 0 and 1x represent the prefix index of the extended node; 2 and 3x represent the prefix index of the leaf node; The value that follows represents the number of shared hexadecimal characters in the paths of these nodes.

[0037] In summary, MPT ensures the integrity of the overall data through the root hash value, uses the extension node to merge keys with a common prefix index, quickly locates the data path through the branch node, and finally stores the specific key-value pair data in the leaf node.

[0038] The present invention manages multiple VM ledgers by unifying MPT, so that a blockchain system can simultaneously support multiple different types of VMs, such as Move VM and EVM. This method not only allows different virtual machines to run independently on the same chain, but also supports interoperability between them, including the sending of transactions, the calling of smart contracts, and the exchange of data.

[0039] First, each VM, whether it is EVM or Move VM, is given an independent "space" in which they can have their own state and execution logic. This design allows each VM to maintain its own state without being affected or interfered with by other VMs. This independence is achieved in the execution engine, which is responsible for distributing transactions to the corresponding VM for processing based on the format of the transaction. The two VMs have independent ledger state spaces, distinguished by key spaces, and each VM can only read and write data in its own address space. Logically, the states of the two spaces remain isolated. The perspectives of different spaces are as follows: Figure 4 shown.

[0040] Secondly, in order to further simplify the management of multi-virtual machine ledgers, the present invention introduces a unified MPT. MPT is an efficient data structure for storing and retrieving large data sets while maintaining data integrity and security. The MPT of the present invention provides a unified interface that can store any type of key, which means that whether it is the state of the EVM or the state of the MoveVM, the same underlying data structure can be used for storage. Figure 3 As shown, the present invention stores and maintains the status of Move VM and EVM through the same key value in the same MPT, but different virtual machines search and update and maintain their respective status through the key value.

[0041] Continue to refer Figure 3 For the data stored in the same node, different prefix indexes are defined to store the state values ​​corresponding to different VMs. For example, x is the prefix index of the state value stored by EVM, and y is the prefix index of the state value stored by Move VM.

[0042] like Figure 4As shown in the figure, although the MPT and state root are unified in implementation, each VM is still limited to its own address space. In other words, the EVM cannot access or modify the state of the Move VM, and vice versa. This isolation ensures the security and independence of each VM, preventing potential errors or malicious behavior of one VM from affecting another VM. In addition, the unified MPT brings other benefits. For example, the process of data synchronization and backup is simplified because all state data follows the same structure and rules. This makes system maintenance easier, while also improving the scalability and flexibility of the system.

[0043] At the implementation level, the unified MPT requires the developers of each VM to comply with a common set of specifications and interfaces, which not only helps to unify the management and processing of data on different VM states and reduce system complexity, but also promotes innovation and collaboration across virtual machines. For example, developers can more easily build services and applications across virtual machines and leverage the unique advantages of each virtual machine to provide a richer user experience.

[0044] Therefore, in an embodiment of the present invention, a method for managing multi-virtual machine blockchain data through a unified MPT is used. The unified MPT stores the state values ​​corresponding to different virtual machines by defining different prefix indexes. Different virtual machines have independent account state spaces. MPT provides a unified interface that can store any type of key. Multiple virtual machines use the same underlying data structure for storage.

[0045] The unified MPT stores the state values ​​corresponding to different virtual machines by defining different prefix indexes. Specifically, the unified MPT stores the state value corresponding to the first virtual machine (e.g., EVM) by defining a first prefix index; the unified MPT stores the state value corresponding to the second virtual machine (e.g., Move VM) by defining a second prefix index.

[0046] The first prefix index is x, and the second prefix index is y. Figure 3 As shown, x stores the state value corresponding to EVM, and y stores the state value corresponding to Move VM.

[0047] Please refer to the following Figure 5 , a method for managing multi-virtual machine blockchain data through a unified MPT in an embodiment of the present invention is described in detail.

[0048] Before the step starts, perform initialization operations and prepare to receive transaction requests.

[0049] Step 10: The execution engine determines the format of the transaction.

[0050] In the specific implementation process of step 10, for example, the transaction type is determined according to the characteristics of the transaction to identify whether the transaction is designed for the first virtual machine or the second virtual machine.

[0051] Before step 10, the method further includes the steps of: receiving a transaction request; parsing the transaction format. In the specific implementation process, for example, a user or a smart contract initiates a transaction request, and after receiving the transaction request, the transaction format is parsed.

[0052] The step of parsing the transaction format specifically includes: analyzing transaction data; and determining the transaction structure and type.

[0053] Step 20: When the format of the transaction corresponds to the first virtual machine, the transaction is sent to the first virtual machine for execution; and when the format of the transaction corresponds to the second virtual machine, the transaction is sent to the second virtual machine for execution. The first virtual machine and the second virtual machine are different.

[0054] In the specific implementation process of step 20, for example, when the first virtual machine is EVM and the second virtual machine is Move VM, the transaction is directed to the corresponding VM according to the transaction type. If the transaction format is identified as corresponding to EVM through step 10, the transaction is sent to EVM, and the transaction is executed by EVM. If the transaction format is identified as corresponding to Move VM through step 10, the transaction is sent to Move EVM, and the transaction is executed by Move EVM.

[0055] Step 30: After executing the transaction, the transaction execution result is stored in a unified MPT.

[0056] In the specific implementation process of step 30, for example, after completing the transaction processing, the results are generated and stored in the same MPT to ensure that the status updates of all VMs can be effectively recorded and tracked.

[0057] Before storing the transaction execution results in the unified MPT in step 30, it also includes: judging the transaction execution results. In the specific implementation process, for example, when a user submits a transfer transaction, the balance of the user's corresponding account must be reduced, and the balance of the other party's account must be increased. Of course, the Miner Fee is also involved in the middle, and the node operator must be transferred. These processes are processed by the VM, and after execution, they are packaged into blocks, the block root is updated, and then the whole network is synchronized. After the vote of all network nodes is passed, the transaction execution is successful, otherwise, the transaction execution fails.

[0058] Different processing is performed according to different transaction execution results. When the transaction execution is successful, the execution steps are: storing the transaction execution results in a unified MPT; and when the transaction execution fails, waiting for re-execution or discarding the transaction.

[0059] After step 30, the transaction process ends and the current transaction session is closed.

[0060] Obviously, those skilled in the art can make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include these modifications and variations.

Claims

1. A method for managing multi-virtual machine blockchain data through unified MPT, characterized in that: The unified MPT stores the status values ​​corresponding to different virtual machines by defining different prefix indexes. Different virtual machines have independent ledger status spaces. MPT provides a unified interface that can store any type of key. Multiple virtual machines use the same underlying data structure for storage, including: The execution engine determines the format of the transaction; When the format of the transaction corresponds to the first virtual machine, the transaction is sent to the first virtual machine for execution; and when the format of the transaction corresponds to the second virtual machine, the transaction is sent to the second virtual machine for execution; After the transaction is executed, the transaction execution results are stored in a unified MPT.

2. The method according to claim 1, characterized in that The unified MPT stores the status values ​​corresponding to different virtual machines by defining different prefix indexes, specifically: The unified MPT stores the state value corresponding to the first virtual machine by defining a first prefix index; The unified MPT stores the state value corresponding to the second virtual machine by defining a second prefix index.

3. The method according to claim 2, characterized in that The first prefix index is x.

4. The method according to claim 2, characterized in that The second prefix index is y.

5. The method according to claim 1, characterized in that The first virtual machine and the second virtual machine are different.

6. The method according to claim 1, characterized in that Before the execution engine determines the format of the transaction, it also includes: Receive transaction requests; Parse the transaction format.

7. The method according to claim 6, characterized in that The format of the parsed transaction specifically includes: Analyze transaction data; Determine the transaction structure and type.

8. The method according to claim 1, characterized in that Before storing the transaction execution results in the unified MPT, the method further includes: Determine the transaction execution results.

9. The method according to claim 8, characterized in that After determining the transaction execution result, the method further includes: When the transaction is successfully executed, the execution step is: the transaction execution result is stored in the unified MPT.

10. The method according to claim 8, characterized in that After determining whether the transaction is successfully executed, it also includes: When a transaction fails to execute, wait for re-execution or discard the transaction.

Images