EVM Migration via Interface Module Segmentation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Ethereum's inefficient consensus algorithm limits its ability to support large-scale commercial applications, and migrating the Ethereum Virtual Machine (EVM) to another blockchain system is challenging due to its inherent binding to specific data storage and access modes, making compatibility with other blockchain technologies difficult.
Innovation Solution
A modular design is introduced to migrate the EVM as a module into a modular blockchain system, isolating block data from execution logic, allowing the EVM to access intra-contract variables through an interface module that performs instruction conversion and calls appropriate blockchain access interfaces, enabling compatibility with various blockchain systems.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If EVM is migrated to another blockchain system, then compatibility with other blockchain technologies is improved, but the complexity of migration increases due to inherent binding to specific data storage and access modes
Solution Approach 1:
The patent segments the EVM system into modular components: a virtual machine instance for execution logic and an interface module for data storage and access. This segmentation allows the EVM to be migrated to different blockchain systems by replacing only the interface module while keeping the core execution logic intact, thereby improving compatibility without proportionally increasing migration complexity.
Solution Approach 2:
The patent introduces an interface module as an intermediary layer between the EVM virtual machine instance and the underlying blockchain data storage system. This intermediary handles the conversion and adaptation of data access modes, shielding the execution logic from system-specific storage details and facilitating easier migration to different blockchain platforms.
2Productivity
If EVM is tightly bound to specific data storage modes, then execution efficiency is improved, but adaptability to different blockchain systems deteriorates
Solution Approach 1:
The patent extracts the data storage and access mode dependencies from the core EVM execution logic and places them in a separate interface module. This extraction allows the virtual machine instance to maintain its optimized execution efficiency while the interface module handles adaptations to different blockchain storage systems, thus preserving productivity while improving compatibility.
Solution Approach 2:
The interface module is designed with universal functionality to support multiple blockchain data storage modes. It can adapt to different underlying systems (Ethereum, Hyperledger Fabric, etc.) while providing a consistent interface to the EVM virtual machine instance, enabling the same execution logic to operate efficiently across diverse blockchain platforms.
3Adaptability or versatility
If modular design is introduced to isolate block data from execution logic, then adaptability to different blockchain systems is improved, but device complexity increases due to additional interface modules
Solution Approach 1:
The patent applies segmentation by dividing the system into two main parts: a standardized EVM virtual machine instance and a configurable interface module. This segmentation creates clear boundaries and responsibilities, making the system more manageable and maintainable despite the added modularity. The interface module encapsulates the complexity of different blockchain protocols, preventing it from propagating throughout the entire system.
Solution Approach 2:
The interface module is designed to be self-configurable and self-adapting to different blockchain systems. It automatically handles the complexity of interfacing with various underlying storage systems, reducing the need for manual configuration and minimizing the operational complexity introduced by modularity. The module serves itself by maintaining compatibility layers without requiring extensive external intervention.
Data Source
Figure 1~2
Figure 3
Figure 4
AI summary
Provided are an Ethereum Virtual Machine-based transaction processing method and apparatus, a device, a program and a medium. A specific implementation solution includes: acquiring, by a virtual machine instance running in a blockchain node, a to-be-processed transaction request; in a process of executing the to-be-processed transaction request, generating, by the virtual machine instance, a data access request for an intra-contract variable and transmitting the data access request to an interface module; performing, by the interface module, instruction conversion according to the data access request to determine an intra-contract variable access interface corresponding to a function of the data access request; and calling, by the interface module, the intra-contract variable access interface for a contract space in a data storage space of a blockchain to access the intra-contract variables in the contract space and feeding back an access result to the virtual machine instance.