Integration of the Ethereum Virtual Machine (EVM)
Overview of MultiversX Virtual Machine (VM)
The MultiversX Virtual Machine (VM) architecture is designed with a clear separation between the VM logic and the node logic. Communication between the VM and the node (host) is facilitated through a construct called VM hooks. Integrating the Ethereum Virtual Machine (EVM) required coupling the existing set of opcodes to the VM hooks, with other necessary adjustments to ensure compatibility.
EVM Implementation in OneFinity
OneFinity’s EVM implementation is based on the Go Ethereum (Geth) "Cancun" release (tag: v1.13.15 from github.com/ethereum/go-ethereum).
Specifics:
Opcodes:
Supported: Most of the opcodes from the base implementation work as expected.
Exceptions: Due to differences between MultiversX and Ethereum, the following opcodes return empty responses:
COINBASE,DIFFICULTY,BASEFEE,BLOBBASEFEE,BLOBHASH.
Gas Fees: Adjustments were made to the gas fees to ensure fairness across the network. Similar operations should result in similar gas consumption whether done via EVM or SpaceVM. Affected opcodes typically involve interactions with the blockchain. Actions like reading/writing from/to the storage, or invoking/creating contracts, delegate responsibilities to the chain. Others, which perform local logic without external data access, have similar costs as other Ethereum networks. Therefore, it's essential to simulate gas consumption using the RPC's dedicated methods, instead of hardcoding values.
Precompiles: These function the same as on any Ethereum network.
MultiversX Integration Highlights
MultiversX's transaction orchestration, including validation, preparation, and security checks, remains unchanged.
MultiversX's specific built-in functions are also accessible from within the EVM. For more details about them, please consult the MultiversX documentation. A relevant example for such a use case is presented within the Interoperability section.
The EVM focuses solely on execution, leaving pre and post-execution processes to MultiversX.
Accounts and Addresses
EVM uses 20-byte addresses, while SpaceVM employs 32-byte addresses. OneFinity bridges this gap by associating a complete set of addresses with each account (those are visible within the explorer). Key details:
Account Structure: Each initialized account (an account for which we have at least one interaction with the chain) has a MAIN address (depending on the initiating ecosystem) and one (or multiple, in the future, in case the implementation is extended) SECONDARY addresses.
Address Generation: SECONDARY addresses are automatically created with unique prefixes to enhance security and prevent malicious actions.
Smart Contracts: Special considerations are applied to the smart contract addresses, as the MultiversX smart contract address format implies a specific pattern.
Interaction flows
When a user sends a transaction involving a valid, uninitialized, Ethereum address, a corresponding MultiversX address is automatically generated. Both addresses are linked to the same account, with the Ethereum wallet owner being the sole operator. The MultiversX address acts purely as an identifier within the MultiversX ecosystem and lacks an associated private key, meaning transactions cannot be signed using MultiversX tools. Here, the Ethereum address is considered the MAIN address, while the MultiversX address is the considered the SECONDARY one.
This setup is also applicable in reverse scenarios.
Conclusion
The outlined method guarantees that identical private keys produce the same addresses across all Ethereum networks.
Last updated