multi-vm first commit by schimih · Pull Request #1036 · multiversx/mx-docs

schimih · 2025-01-15T14:51:38Z

Description of the pull request (what is new / what has changed)

Did you test the changes locally ?

yes
no

Which category (categories) does this pull request belong to?

document new feature
update documentation that is not relevant anymore
add examples or more information about a component
fix grammar issues
other

andreibancioiu · 2025-01-15T17:06:05Z

docs/sovereign/standalone-evm.md

+## 3. Abstraction Layer: MultiversX & EVM Interfaces
+
+To allow the EVM to function within MultiversX, we introduce a layer that bridges EVM interfaces with MultiversX components. The core interface it uses is the `BlockchainHookInterface`, which grants access to critical blockchain data, state, and transaction information.
+### 3.1 Reading & Writing to Storage


Missing newline before header.

andreibancioiu · 2025-01-15T17:06:37Z

docs/sovereign/standalone-evm.md

+
+After EVM execution finishes, we need to commit the resulting state changes to the blockchain. The EVM will use the `outputContext` component, which (together with the `storageContext`) tracks modified accounts and storages. It also creates the final `vmOutput`, which the `scProcessor` in `mx-chain-go` will then validate and apply to the blockchain (the trie) if everything is correct.
+
+---


I think we didn't use the separators --- before. Maybe remove them?

andreibancioiu · 2025-01-15T17:07:20Z

docs/sovereign/standalone-evm.md

+### 3.1 Reading & Writing to Storage
+
+- **Reading Storage**: When an EVM opcode attempts to read data from the storage (e.g., `readStorageFromTrie(key)`), it should invoke `blockchainHook.ReadFromStorage(scAddress, key)`.
+        Internally, this call goes through the `storageContext` component, which manages reads from local cache if a key has already been accessed or modified during the current transaction.


Indentation not necessary.

andreibancioiu · 2025-01-15T17:08:29Z

docs/sovereign/standalone-evm.md

+
+- Start from the SpaceVM code.
+- Replace the current executor (WASMER) with the EVM executor.
+- During EVM opcode interpretation, invoke the storageContext and meteringContext functions to manage state changes and track gas consumption.


Formatting / code components as code.

andreibancioiu · 2025-01-15T17:09:51Z

docs/sovereign/standalone-evm.md

+
+### 6.2 Token Storage in EVM
+
+Token balances (like ERC20) live in the contract’s own storage. The contract will use the last 20 bytes of a user’s MvX address when recording ownership or balances. If an opcode like `GetCaller` is executed, it returns only the last 20 bytes from the `ContractCallInput.Sender`.


contract's instead of contract’s.

andreibancioiu · 2025-01-15T17:12:54Z

docs/sovereign/standalone-evm.md

+
+The **WASM VM** supports a public function `ExecuteOnDestOnOtherVM` via the **BlockchainHook** interface. If a new VM is fully integrated, it can be added to the `vmContainer` component with a new **baseAddress**. Below is an example table illustrating potential base addresses for different VMs:
+
+| VM Name     | Example Base Address | Notes                                                                            |


Maybe "VM Type" instead of "base address"? Or "address suffix"? (just an opinion)

Address Suffix

andreibancioiu · 2025-01-15T17:14:39Z

docs/sovereign/standalone-evm.md

+
+---
+
+## 10. ESDT ↔ ERC20 & ESDTNFT ↔ ERC721


No other sections between # 7 and # 10. Maybe drop the numbering in all headers?

true, I had some other details, considered unnecessary afterwards.

andreibancioiu · 2025-01-15T17:15:51Z

docs/sovereign/standalone-evm.md

+- **ERC721 (NFTs)**: An **ESDTNFT** wrapper can track ownership and minted tokens, providing `approve()` and `transferFrom()` methods that mirror standard ERC721 functionality.
+- **ERC1155**: This multi-token standard can likewise be “wrapped,” allowing ESDT-based multi-tokens to be interfaced with EVM-based dApps expecting ERC1155 contracts.
+
+By handling all “pull” transfers inside dedicated wrapper contracts, MultiversX preserves its **secure-by-design** “push” transfer model while still enabling compatibility with dApps that rely on ERC-style approvals. 


“pull”, “push” non-standard quotation marks.

andreibancioiu · 2025-01-15T17:18:35Z

docs/sovereign/vm-intro.md

+The MultiversX protocol is designed so that integrating a new executor, a new processor, or even a completely new VM is straightforward. In essence, any new VM only needs to implement the `VMExecutionHandler` interface. Currently, there are two VMs running on MultiversX:
+
+- **WasmVM**: Handles general smart contracts running on WASM.
+- **systemVM**: Specialized for defined system smart contracts written in Go.


Maybe "builtin" instead of "defined"?

andreibancioiu · 2025-01-15T17:20:01Z

docs/sovereign/vm-intro.md

+
+When considering the EVM or other VMs, on MultiversX, it’s important to note that developers will likely want to interact with WasmVM contracts as well. Put simply, a smart contract should be able to interact with both WasmVM and other VM contracts in a uniform way, and that abstraction must happen at the VM level. The WasmVM already handles this by smartly calling the `ExecuteOnDestOnOtherVM` endpoint as needed.
+
+If we look further down the **STACK** we have SpaceVM which can actually accommodate multiple **EXECUTORS**. In the case of current mainnet/sovereign SpaceVM the **EXECUTOR** is *WASMER2.0* with a few additions from our side. Wasmer is written in rust and SpaceVM is written in GO. The SpaceVM has a big set of **OP_CODES**, from storage handling, to memory handling to crypto operations, big floats, and more. These **OP_CODES** are represented as pointer functions, written in GO and they have an access pointer. The executor, our modified Wasmer, receives this set of functions as a LIBRARY and when a SmartContract calls one of the **OP_CODES**, this calls the internal library added to WASMER which gets executed in the GO code of SpaceVM.


Maybe stack instead of **STACK**? Or "if we look under the hood"?

sasurobert · 2025-01-15T18:31:46Z

docs/sovereign/other-vm.md

+# Other-VM
+
+:::note
+As the MultiversX Sovereign Chains ecosystem grows, additional VMs will be added and described here over time. Each new VM will follow the same integration pattern: assigning a unique base address, implementing the appropriate interfaces (such as `VMExecutionHandler`), and supporting cross-VM calls via the `blockchainHook` mechanism.


actually SpaceVM implements every necessary interface and the new VM needs to only change the EXECUTOR part inside the SpaceVM.

sasurobert · 2025-01-15T18:32:49Z

docs/sovereign/vm-intro.md

+- **WasmVM**: Handles general smart contracts running on WASM.
+- **systemVM**: Specialized for defined system smart contracts written in Go.
+
+For sovereign shards, we introduced the option for a WasmVM smart contract to call a systemVM smart contract through the `BlockchainHookInterface`, specifically via the `ExecuteOnDestOnOtherVM` endpoint. This is necessary because both VMs reside in the same shard on sovereign shards. On the mainnet, however, WasmVM contracts can interact with systemVM contracts only through an asynchronous call, since systemVM exists exclusively on the metachain.


change every WasmVM -> with SpaceVM and WASM executor.

andreibancioiu · 2025-01-16T07:52:55Z

docs/sovereign/standalone-evm.md

 The **WASM VM** supports a public function `ExecuteOnDestOnOtherVM` via the **BlockchainHook** interface. If a new VM is fully integrated, it can be added to the `vmContainer` component with a new **baseAddress**. Below is an example table illustrating potential base addresses for different VMs:

-| VM Name     | Example Base Address | Notes                                                                            |
+| VM Name     | Address Suffix   | Notes                                                                            |


Sorry, I meant prefix 🙈

multi-vm first commit

f6ca7a2

schimih self-assigned this Jan 15, 2025

adding note

3751a6b

andreibancioiu reviewed Jan 15, 2025

View reviewed changes

sasurobert reviewed Jan 15, 2025

View reviewed changes

fix after review

1143084

sasurobert approved these changes Jan 16, 2025

View reviewed changes

andreibancioiu approved these changes Jan 16, 2025

View reviewed changes

schimih merged commit 9449803 into development Jan 20, 2025
3 checks passed

schimih deleted the multi-vm-sovereign-14012025 branch January 20, 2025 14:47


		After EVM execution finishes, we need to commit the resulting state changes to the blockchain. The EVM will use the `outputContext` component, which (together with the `storageContext`) tracks modified accounts and storages. It also creates the final `vmOutput`, which the `scProcessor` in `mx-chain-go` will then validate and apply to the blockchain (the trie) if everything is correct.

		---


		### 6.2 Token Storage in EVM

		Token balances (like ERC20) live in the contract’s own storage. The contract will use the last 20 bytes of a user’s MvX address when recording ownership or balances. If an opcode like `GetCaller` is executed, it returns only the last 20 bytes from the `ContractCallInput.Sender`.


		The WASM VM supports a public function `ExecuteOnDestOnOtherVM` via the BlockchainHook interface. If a new VM is fully integrated, it can be added to the `vmContainer` component with a new baseAddress. Below is an example table illustrating potential base addresses for different VMs:

		\| VM Name \| Example Base Address \| Notes \|


		When considering the EVM or other VMs, on MultiversX, it’s important to note that developers will likely want to interact with WasmVM contracts as well. Put simply, a smart contract should be able to interact with both WasmVM and other VM contracts in a uniform way, and that abstraction must happen at the VM level. The WasmVM already handles this by smartly calling the `ExecuteOnDestOnOtherVM` endpoint as needed.

		If we look further down the STACK we have SpaceVM which can actually accommodate multiple EXECUTORS. In the case of current mainnet/sovereign SpaceVM the EXECUTOR is WASMER2.0 with a few additions from our side. Wasmer is written in rust and SpaceVM is written in GO. The SpaceVM has a big set of OP_CODES, from storage handling, to memory handling to crypto operations, big floats, and more. These OP_CODES are represented as pointer functions, written in GO and they have an access pointer. The executor, our modified Wasmer, receives this set of functions as a LIBRARY and when a SmartContract calls one of the OP_CODES, this calls the internal library added to WASMER which gets executed in the GO code of SpaceVM.

Conversation

schimih commented Jan 15, 2025

Description of the pull request (what is new / what has changed)

Did you test the changes locally ?

Which category (categories) does this pull request belong to?

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants