SovereignChains will have another big important feature to tackle, to make it an interoperability layer between different ecosystems. To do this, we together with ecosystem partners and builders create a set of components which can be turned on and off depending on the needs of the particular SovereignChain.
If we think about our Virtual Machine, it has 2 parts, GO and Rust, but more clearly, One which handles OPCODES, State, Transfers and one which is the executor. Furthermore, starting from the address model, we enable multiple VMs to be run in the system, and we have a clear implementation of how these VMs can call each other, and it is independent of the VMs (implemented with the help of the blockchainHook).
The basic idea is to use our modular design, multi VM capabilities and create direct connections using existing technologies from the market to create a set of interesting connections.
Now let’s look at the example of EVM, how to run contracts and how to make a WASM+EVM SovereignChain as an L2 on Ethereum, creating a chain which creates settlement towards Ethereum and MultiversX. Here we will also leverage ZK-EVM technology, specifically Type1 from Polygon.
-
SovereignChain by default makes settlements on the MultiversX mainchain for all the ESDT assets
-
EVM is implemented deep inside the SpaceVM codespace, specifically, it leverages all the mx-chain-vm-go modules and functions, but instead of running a WASM instance, we run the EVM interpreter. The code allows this.
-
As SpaceVM is used, that one already has the ExecuteOnOtherVM function implemented, thus we have direct composability between WASM and EVM contracts.
-
A wrapper contract standard is built from ESDT to ERC token standards and one wrapper standard from ERC to ESDT. Thus achieving interoperability of tokens.
-
Now we do NOT NEED to settle everything that happens on the WASM/protocol side (actually would need to create different ZK circuits for the ESDT transfer opcodes, not only pure WASM) on Ethereum, we could settle only the execution of the EVM codes. This is somewhat the same rationale that you do not need to settle everything on a gaming chain, but the assets.
-
Here comes ZK-EVM type1
1. Upgrading Every EVM Chain to ZK: Introducing the Type 1 Prover
2. GitHub - 0xPolygonZero/zk_evm -
This enables for any ecosystem to have its own part of EVM code, running validators and creating blocks to have ONE prover node attached to it which will create the ZK-EVM proofs of execution for that chain. The resulting proof can be sent to Polygon aggregated layer or directly to Ethereum.
-
This way a SovereignShard could become an L2 on top of Ethereum as well, this is the choice of the validators who run that shard.
Now this is for Ethereum, but we can imagine similar structures for other ecosystems as well, like Solana SVM, SUI/Aptos MoveVM, Near WASM VM. But it will depend on teams who launch their sovereign chains where they want it or not.
In the case of Bitcoin L2, there are several projects trying to innovate on BitVM, which builds on top of the taproot upgrade. The Bitcoin L2 Opportunity. How to Resist the Capture of Bitcoin by… | by Mohamed Fouda | Alliance | Medium Here, some of the projects are running EVM, other Calrity (WASM) and zkVM (built in Rust). The same way of having dual VM running on a SovereignShard, creating a set of contracts for token interoperability and finally having to settle only a part of the tokens on Bitcoin would be a way for a SovereignChain to become L2 Bitcoin as well, while being and settling ESDT stuff on MultiversX mainchain.
When it comes to IBC, we can have several ways of doing so, right now exploring the bath with Union.build and to see how their ZKIBC works. Actually Axelar uses Comsos SDK, and we built a bridge towards Axelar to be run on the mainnet.
SovereignChains could also do the architecture presented above: running SpaceVM and CosmWASM in parallel and creating a set of contracts for interoperability between tokens. On CosmWASM there is a complete module for IBC: cosmwasm/IBC.md at main · CosmWasm/cosmwasm · GitHub
SovereignChains in the presented form could create interesting market dynamics, where people would bring multiple products from other chains directly into a SovereignChain SDK, while still having the seamless interoperability towards the mainchain. This would mean more inflow of developers into the MultiversX ecosystem and as the interoperability between assets, projects, and chains is resolve at the SDK level.