Sovereign Shards - MIP-7 - part - 1


1. Why?

The MultiversX blockchain is a fully sharded architecture, which is scalable, can process tens of thousands of transactions per seconds and developers can launch decentralized applications on top of it using smart contracts. The system also has the in-protocol token standard named: ESDT which makes transferring tokens simple, inexpensive and scalable. As the network grows, shards are created and the system is scaling with in-protocol tokens as well, achieving true horizontal scaling. With later additions, we researched and defined a feature to introduce parallelization of processing in the same shard, thus enabling direct vertical scaling of the whole system as well. The system is decentralized with 3200 validators running, public, open and the base token is EGLD.

However, there are systems and applications which need more customizability than a token and a smart contract can offer. App specific blockchains are blockchains that are customized to run a set of specific applications, rather than relying on a general-purpose platform like MultiversX. There are several reasons why app specific blockchains are a must for some developers and use cases.

First, by dedicating the entire blockspace and computational resources to one application, app specific blockchains can process more transactions per second, reduce latency, and lower fees. This is especially important for applications that require high throughput, low latency, or complex logic, such as gaming, high frequency trading, or social media.

Second, app specific blockchains can offer more flexibility and sovereignty than shared platforms. By building their own blockchain, developers can customize various aspects of their application, such as the security model, the fee token, the governance mechanism, the virtual machine. Some applications may want to implement novel incentive schemes, tokenomics models, or user experiences that are unique to their application. This can help developers attract and retain users, as well as create network effects and competitive advantages for their application. Games especially need free transactions for state-changes triggered by their own validators, free transactions for premium users, customizability of in-game economics and more.

Institutions which want to use blockchain technology, often want to run their own specifications (contracts, language, VM, nodes), and they often want to run privately.

With Sovereign Shards we want to give an SDK for all builders to run their own highly efficient chains, but which is seamlessly connected and integrated into the global markets of MultiversX. Give developers freedom, give users the power to enjoy all dApps seamlessly, make it feel like they are on a single blockchain. One wallet to interact with all. Composability and interoperability built into the design and architecture of the system. New paradigms to leverage existing infrastructure and enhance the user experience. Usability of all chains simplified by systems like relayed transactions and paymaster smart contracts.

Through using a sovereign shards builders can leverage all the technology and work put behind the wallet, explorer, xPortal, microservices and so forth.

2. The history

The Cosmos ecosystem started with an idea of application specific blockchains which are working together through a specified communication layer of IBC. In the case of Cosmos each project starts his own chain with his own set of validators and makes a completely new ecosystem. They register for IBC to move tokens from one chain to another through IBC and that’s all. Security wise the validator on the main hub does not know anything about side hubs. Each chain has its own security model and can exist independently - most of them do not even connect to IBC. The Cosmos SDK is relatively easy to use, but there is a generally high development cost, lower network effects and most of the chains live on their own island, without connection to global markets.

Polkadot went a little bit further with the idea by introducing shared security. Side-chains in Polkadot have to bid to be included and connected with the main chain. Validators are randomly assigned at each epoch to a side-chain which can work relatively simple and independent. State finality is written through WASM based smart contracts. In Polkadot, bridges connect to the Relay Chain and are secured through the Polkadot consensus mechanism, maintained by collators. All validators are randomly assigned to side-chain, no special customizability in those terms.

The two next examples are Polygon supernets and Avalanche subnets. Both of them have super similar architecture. Polygon is an L2 on top of Ethereum and offers an L3 solution on top of itself. Avalanche is a scalable L1 solution using DAGs. Using the SDK offered by one of these teams, projects can easily start their own chain and through a set of scripts and configs can put together a bridge between their chain and the mainchain. The used architecture for the bridges is from ChainSafe.

In the case of Polygon supernets can be run completely independently, with your own set of validators or it can be run through using the infrastructure of a selected set of validators. On Avalanche, validators stake AVAX on the mainchain they validate on the mainchain and select whether they want to validate on the subnet or not.

In both cases, the one who sets up the side-chain can add manually the public keys of the validators he agreed to work with and can start the chain. Both of them can be run privately, without sharing data to the outside (for this you need your own validators). In the case of Polygon, for each side-chain the validators have to stake extra in a different contract. All in all, both in Polygon and Avalanche we can think about of having a set of multi-signature smart contract where validators stake and from where they can be slashed through various methods and have a set of bridge contracts through which users can move funds from the main-chain to the side-chain.

3. The problems with Layer2s

Right now there are various Layer2 solutions built on top of Ethereum to scale it (not necessarily application specific chains) which have made all the wrong decisions in their implementations. Funds on L1 are in general secured by a small multiSignature with admin wallets (2 out of 3, 3 out of 5), liquidity is fragmented, applications are fragmented. Users do not have the same account on L2s, bridging is done by special apps (bridges) thus the user has to trust more. The user needs specific gas tokens in various L2s, it is just a complete mess. Hard for users, hard for builders, hard for adoption.

Tons of copy-pasted applications from one chain to another, users have a hard time using it, adapting to every such deploy. Users first need to move funds around from one wallet to another to be able to use the dApps. No default interoperability, no default composability. All copy pastes are bringing everything which is wrong on the base layer, like approve and transferFrom of ERC20 tokens, reentrancy issues, overflows, impersonation. The same user can be scammed, fished in every chain.

4. The features of Sovereign shards

The sovereign shard is a completely independent chain with smart contract processing, ESDT transfers, delegation, staking, governance, guardians and all the features the MultiversX main chain has. It is configurable according to the developer, features can be turned on/off, new features can be added on protocol level.

The developer can choose between proof of authority, proof of stake, delegated proof of stake, secure proof of stake models. Number of minimum/maximum of validators can be set, with any additional criterias (like staking different tokens). Fee model and gas token is configurable as well. By implementing the VMExecutionHandler interface, developers can build multiple VMs, which can be connected to the WasmVM and SystemVM as well for seamless interactions and built in composability.

List of high level features:

High performance: > 4000 Defi/Gaming Txs per seconds.

  1. Achieved by new consensus model - which enable 90-95% of consensus time to be about processing :
  2. Less nodes with high performances can be chosen.
  3. Specialized chains with WASM WARM instances - can keep all the contracts as instances and execute at almost machine level speed.

Configurable set of features:

  1. Private vs public
  2. Staking setup, delegation setup.
  3. Smart contracts enabled
  4. ESDTs enabled
  5. Configurable gas and transaction fees - maybe make it free in case of private chains, free for validators, free for a set of users. Define gasToken as ESDT.

Virtual Machine - configurable

  1. By default SystemVM (written in GO executing GO SCs) and WasmVM
  2. Build new VMs by your liking
  3. EVM, Move, other interpreters or specialized VMs
  4. Composable VM to VM calls through BlockchainHook ExecuteOnOtherVM

Built-in bridge between sovereign chain and MultiversX Network without relayers:

  1. MultiversX to Sovereign
1. User deposits token in safe contract which he wants to bridge
2. Validators in the sovereign chain follow the mainchain headers and will push to the sovereign chain the header, the bridge txs and the proof for it.
3. Leaders include proofs of execution from mainchain, right now in terms of adding mainchain header hashes in the sovereign chain header, validators verify it and sign sovereign chain block only if all steps are correct. The notifier/proof system provides an abstracted interface through which sovereign nodes can verify and validate the authenticity of data.
4. Incoming Txs are processed by Incoming Txs processor after verifying the proofs. User receives tokens on the sovereign chain.
  1. Sovereign to MultiversX:
1. User sends token to bridgeSC on sovereign
2. The validators create a proof on the sovereign chain, for a batch of transfers, that will be sent to the mainchain bridgeSC.
3. Validators add this information to the sovereignChainBlockBody. Otherwise the block is not signed.
4. Leader will push the created txData to the mainchain
5. BridgeSC on the mainchain verifies the proof and executes the transfers.
6. Sovereign validators will notarize the event of finishing transfer on the following sovereign block. By receiving the attestation logEvent directly from the mainchain.

5. Sovereign Shard bridges

In case of the MultiversX chain we have a clear definition of how a token transfer is happening between 2 shards.

“Our cross-shard transaction strategy uses an asynchronous model. Validation and processing is done first in sender’s shard and then in receivers’ shard. Transactions are first dispatched in the sender’s shard, as it can fully validate any transaction initiated from the account in this shard – mainly the current balance. Afterwards, in the receivers’ shard, the nodes only need proof of execution offered by metachain, do signature verification and check for replay attack and finally update the balance for the receiver, adding the amount from the transaction. Shard 0 processes both intra-shard transactions in miniblock 0 and a set of cross-shard transactions that have addresses from shard 1 as a receiver in miniblock 1. The block header and miniblocks are sent to the metachain. The metachain notarizes the block from shard 0, by creating a new metachain block (metablock) that contains the following information about each miniblock: sender shard ID, receiver shard ID, miniblock hash. Shard 1 fetches the hash of miniblock 1 from metablock, requests the miniblock from shard 0, parses the transaction list, requests missing transactions (if any), executes the same miniblock 1 in shard 1 and sends to the metachain resulting block. After notarization the cross transaction set can be considered finalized. Shard 0 finishes the block and creates a miniblock for shard 1. Metachain validates and verifies the signatures of validators in shard 0. Shard 1 is forced to process all miniblocks having as destination Shard 1, this information is written in the metachain header.” from

Idealistically speaking we should create a system like cross-shard transfer of tokens for all the newly created sovereign shards. As we know cross shard transactions are secure, fast, efficient and they do not rely on a set of bridge validators/relayers.

One of the most important aspects of the sovereign bridge has to do with not having any relayers, not needing an entity which pushes data from one chain to another, but implementing the interoperability automatically into the Sovereign Chain SDK client and a set of contracts deployed on sovereign genesis. Also, all the validation of bridged assets will be done by verifying proofs, adding signatures of all eligible validators from sovereign. Not only to have the validation complete, but verifiable that there is no mistake - like no missed transaction, no double spend, no missed information. So, validation has to make sure that all bridge operations are in their complete format. The same way validators on destination shard ensure that every cross shard transaction is included in the proposed block.

1. Mainchain to the Sovereign Shard:

Validators from the sovereign shard run a notifier service which sends information from the mainchain when there is a bridge transaction from the mainchain to the sovereign shard. The validators can connect to their own nodes for the notification events, or they can connect to the public notifier services.

Every time the leader sees a new header from the mainchain, he tries to include it in the block which he is currently building: specifically adds the MultiversX ShardHeaderHash to the SovereignShardHeader, if there are bridge transactions from the mainchain, the protocol obliges the leader and validators to process all the transactions if they want to add the ShardHeaderHash. Exactly how destination shard processes in case of cross shard transactions. One SovereignShardHeader can contain a list of ShardHeaderHashes, and the leader add only those ShardHeaders which were final on the mainchain.

If the MultiversX ShardChain Block contains incoming bridge transactions, those must be added and executed in the sovereign chain. The same as destination me miniblocks. The leader cannot add a NEW MultiversX HeaderHash into the list if we did not execute all the transactions from the last one. The leader in the Sovereign Shard has the job of collecting all the incoming bridge transactions and creating a miniblock out of it. This is the first thing in the Sovereign Shard we should process - exactly like DestMe transactions. Technically speaking: the validator receives block data through go-notifier - which selects and prepares the relevant data for the sovereign chain. The prepared information is pushed to the sovereign chain client. The prepared data contains a proof of execution, data availability, correctness and finality for those transfers. The name of this miniblock is “INCOMMING TXS”

The validators on the sovereign chain will do the same process and verify if the thing the leader created is correct or not. The validators are connected to the mainchain, will run the header verification, incoming transaction creation, proof verification and finality checks. If any of those fails, the validators do not sign the block, thus the block is not created.

The incoming bridge TX can be executed without GAS on the Sovereign Chain and there is no need for a Smart Contract on the Sovereign Chain - treat these transactions as DestME ESDT transfers. This makes the execution super fast as well.This is a complete integration, complete coupling of the sovereign chain to the MultiversX chain.

For the user it is super simple, just the transaction on the MultiversX chain directed towards the bridge contract, and he will receive it if the tx was correct on the other side - on the sovereign chain. Another highly important aspect here is that execution and transfer on the sovereign shard for the incoming transactions will be done as the initial user as the sender and revert will go back on the bridge to the user. The fact that the user is the sender even after the bridge process, means seamless interaction for the user and seamless interoperability. The user will interact cross-chain with applications directly as he would do it only using the mainchain. The importance of this aspect is hard to overstate.

In terms of contract on the MultiversX chain it will be a simple ESDTSafe contract. The user will be able to deposit a token and an amount and with a defined destination address and the contract call if the user wants an execution.

Endpoint: deposit@address@functionToCall@arguments@gasLimit - it receives a MultiESDTNFTTransfer(this can be an NFT, multiple tokens of multiple types). The contract verifies if address is valid and generates a specific logEvent:

Identifier = deposit

  • Address = scAddress
  • Topics = address, LIST<tokenID, nonceAsBytes, valueAsBytes/ESDTTransferData>
  • Data = localNonce (increasing), functionToCall, Arguments, gasLimit

ESDTTransferData contains value and ESDTMetadata for NFTs/SFTs/MetaESDTs. This means that not only token and value is transferred but the whole attributes and information with it.

Check on gasLimit to be under MaxValue. (300million)

That is all it is needed in terms of safe contract on the MultiversX chain. This contract will hold the tokens and from the generated logEvents the Sovereign chain validators will generate the incoming txs miniblocks and execute those on the sovereign chain.

A set of specific features which can be customized in this contract at deploy time, and can be changed only through BLSMultiSig of all eligible validators of sovereign in later stages:

  1. General Fee Model: add a fee (first token of MultiESDTNFTTransfer) and a fee token.

    1. By default Mainchain to sovereign will be set for free
  2. WhilteList/BlackList of tokens: a module in which tokens can be whitelisted for transfer

    1. By default this module is not active, so all tokens can be transferred

On the Sovereign chain for bridging from MultiversX to Sovereign there is no need for a smart contract as the prepared transactions are directly executed as destinationME transactions. (they were executed fully on mainchain - we now need to add the incoming ESDTs to the defined destination accounts).

From the logEvents generated by the ESDTSafe contract, the sovereign chain notifier prepares the Extended Shard Header structure and the Incoming Txs miniblock. All the validators do this. If the leader wants to finalize blocks and include mainchain shard headers it must include all incoming txs from that block. Consensus will verify it. This means that the TokenIDs from the mainchain will be the same on the Sovereign Shard as well.

In order to not have collision of ESDT Token IDs between mainchain and sovereign, and between sovereign to sovereign. For every deployed Sovereign a new prefix is added when registering tokenIDs on the ESDT SC. It can be a simple letter (“s”) or an increasing nonce when deploying new sovereign shards. Information of last deployed sovereign shard can be read from the sovereign chain factory SC, discussed in details later.

By doing this - we will see a clear distinction between the ESDT tokens by origin when operating on the sovereign chain. As the tokenID of the mainchain tokens is without the new prefix/suffix.

2. Sovereign Shard to Mainchain:

The Sovereign Validators Job is to sync the mainchain and to push the bridge TXs, plus it will have the job to make the transfers the other way around as well.

First, there are 2 types of tokens when coming from Sovereign to Main - those which were firstly bridged from Main to Sovereign (the liquidity for these is in the safe contract on Main) (token type A) or NEW tokens - bridged firstly from Sovereign from Main (token type B). For the second one, originally issued on the sovereign, there is a need to create (issue the token first) and add localMint, nftCreate roles for the bridge contract - but will go into details later.

  1. Users from Sovereign deposit the tokens in the bridge contract on the Sovereign Shard - this will burn the token (for token type A) or keep in the safe for token type B.
  2. The Sovereign chain creates the next block and finalizes it.
  3. Out of all the transactions which are of type OUTGOING TXs (Bridge to MultiversX) each validator on the sovereign chain must create a compressed operations data which is going to be executed on the bridge smart contract of
  4. The HASH of the outgoing txData is added by the leader to the Header of the Sovereign Shard block
  5. All the validators on the sovereign shard have to reach the same conclusion, will sign the actual same header and the leader will combine all the signatures through the BLS multiSignature.
  6. The job on the Sovereign Shard is finished - now the leader posts this signed header to the MultiversX chain and the list of OutGoingTxs, all signed and verified through BLSMultiSignature. The txData on MutliversX contains the signed header of the sovereign chain, which contains the outgoing operations data hash, the full argument of the outgoing operations.
    1. The contract validates the signed header - checks BLS multisig
    2. Verifies if hash(outgoing operations data) = header.outgoingOpsHash
    3. The bridge contract will start to execute all the mentioned operations. The operation means to do TransferESDT/MultiTransferESDTNFT from the contract to specific addresses for token type A. Minting/CreateNFT+AddQuantity and Transfer those tokens to the given addresses.
    4. The leader uses his own hotwallet on Main chain to post the transaction, no centralized services included, no relayers. Building towards complete decentralization and independence.

So following the IDEA of finality given by MultiversX for the Sovereign Chain - the processing and consensus verifies that the outgoing operations were correctly executed on the main chain.

  1. Sovereign chain Header X has an outgoing operations hash

  2. Main chain executes the Outgoing operations from Header X in one of the next few blocks.

  3. Sovereign chain is always in sync with the main chain and every multiversX header hash is followed, added into the sovereign chain header data. As discussed previously - not only added, but validated by every sovereign chain validator/observer/leader.

  4. Finality gadget (fork detector) will finalize on Sovereign chain Header with Nonce X, only when in Sovereign Chain Header with Nonce X + N there is the confirmation that on Main Chain the Outgoing operations were executed for the previous header.

  5. By coupling this to the internal finality - the system makes sure that validators will push these outgoing TXs to the main chain - furthermore new incentives can be added for pushing and paying for those transactions on multiversX - collected FEEs goes to the leader and validators (10% to leader, the rest is distributed to validators on sovereign chain).

  6. Finality of Nonce X cannot come after finality for Nonce X + M - meaning that outgoing operations must be executed in order - and without having any gaps.

  7. The validation of an outGoingTx is going to happen through generating a logEvent from the mainchain, which is pushed towards the sovereign shard. More details at the smart contract section.

As the Sovereign Chain validators sync - thus execute the blocks from the MultiversX shard - they will execute Validator Set Changes as well after each end of epoch - thus the header validation methods will continue in a normal way. Executing MultiversX blocks is a parallel process, it is always a preparatory things for finality and bridge operations.

Smart Contracts on Sovereign for Sovereign to mainChain bridging:

ESDTSafe contract is the only contract we need on sovereign shards. The user will call deposit@address@functionToCall@arguments@gasLimit function on the ESDTSafe contract, the contract verifies the validity of the address, checks whether the tokenID is originally from the mainchain, and burns those tokens.

The contract emits a logEvent the same way as in mainchain, and the process of creating OutgoingTXs and OutGoingTXData will generate a token operation out of the logEvent.

Identifier = deposit

  • Address = scAddress
  • Topics = address, LIST<tokenID, nonceAsBytes, valueAsBytes/ESDTTransferData>
  • Data = nonce (increasing from ESDTSafe contract), functionToCall, Arguments, gasLimit

From this we generate address@list<tokenID, nonceAsBytes, valueAsBytes>functionToCall, Arguments, gasLimit and append to the previously generated OutGoingTXData for the current block. The combined OutGoingTXData is BLS MultiSigned by all the validators from the Sovereign Shard as part of the consensus. It is verified at consensus level. The system will split the OutGoingTXData into multiple txs according to the accumulated gasLimit which is counted for the execution.

Smart Contract on Mainchain for Sovereign to mainChain bridging:

SovereignMultiSigContract is created and is the parent of the ESDTSafe contract, and only the sovereignMultiSigContract is allowed to transfer out funds from the ESDTSafe contract.

The OutGoingTXData BLS MultiSigned by the validators will be put inside a mainchain transaction and sent by the leader of the Sovereign shard for the current block. This transaction contains a set of token operations for a set of addresses.

txData = bridgeOps@LIST<address<LIST<tokenID, nonceAsBytes, valueAsBytes>,functionToCall, Arguments, gasLimit>>@Nonce@BLSMultiSig

The sovereignMultiSigContract first verifies if the BLSMultiSig is valid and whether it is signed by 67% of the BLSPubkeys registered in the sovereignMultiSigContract. If yes, the contract calls with the ESDTSafe contract to transfer the set of tokens. The ESDTSafe contract will iterate on the given list and make a multiESDTNFTTransfer to the given addresses with the given tokens.

The contract emits a logEvent the same way as mainchain to sovereign ESDTSafe SC does, in order to keep track of the processed outgoing transactions. This logEvent will be pushed towards the sovereign shard, in order to notarize the finalization of processing of the OutGoingTxData. This will close the loop of processing and offer utmost security for all funds.

Identifier = bridgeOps

  • Address = scAddress
  • Topics = sender, hash(outGoingTxData)
  • Data = nonce - increasing from internal storage

The created event is an attestation that the outGoingTx was executed on the mainchain, and using this attestation on the sovereign shard, the rewards can be distributed from the accumulated fees.

Bridging back and forth tokens which are originally from the Sovereign Chain:

In order to bridge tokens from the sovereign chain to the mainchain, first a new ESDT token has to be created on the mainchain and burn/mint roles have to be given for the ESDTSafe contract.

First - when a project wants to bridge from sovereign to the mainchain for the first time a selected ESDT token ID, he needs to make a special transaction towards the bridgeSC on the Sovereign chain. registerNewESDTForBridging@ESDTTokenID@tokenType. This endpoint is with a defined fee in WrappedEGLD (at least 0.5wEGLD as that is the price of issuing a token on the mainchain). After this endpoint is called, a defined set of rounds on mainnet (15 * 6 seconds) has to pass before enabling the actual bridge of tokens. The constants can be changed.

When registerNewESDTForBridging is executed with success, a new event is added into the OutGoingTxs from the sovereign shards, added to the generated outgoing TX data and signed by consensus.

On the mainchain, after verification for BLS multisig, ESDTSafe contract is called and told to execute a full registration of the ESDT token on the mainchain. This will be done by calling “registerAndSetAllRoles” on metachain ESDT system SC. The ESDTSafe contract will save the link between sovereignChainTokenID and mainChainTokenID. The bridge SC in case of Sovereign shard will need to incorporate the ESDTSafe contracts endpoint of deposit@address and in case of tokens which originated on the sovereign shard on deposit the local burn method is called.

Decision of whether a token ID originated from the sovereign can be done by verifying the suffix/prefix of the tokenID as explained above. In case a tokenID originates on a sovereign shard, the SC will check if registerNewESDTForBridging was called before. After successful execution of the bridgeSC , the outGoing TX is formed as usual.

On mainchain, after verification for BLS multisig, ESDT safe contract is called, ESDT safe verifies if tokenID is originally from sovereign, then mints the new tokens (creates NFTs if needed) and sends to the destination.

When bridging the tokens back from mainchain to sovereign, the ESDTSafe contract will check on deposit if the tokenID is from sovereign or not (by checking the storage whether there was a link previously created or not). If it is from sovereign it will burn the received tokens and change logEvent for MultiversX to Sovereign - where tokenID will be the one for the sovereign shard. In the topics we add the bridgeSC address from sovereign and the destination address as well.

Identifier = deposit

  • Address = mainchainSCAddress
  • Topics = sovereignBridgeSCAddress, destAddress, LIST<tokenID, nonceAsBytes, valueAsBytes/ESDTTransferData>
  • Data = block round as bytes

So in case of Mainchain contracts, if the tokenID is from sovereign - the system BURN and MINT functionality/Create functions (create in case of nonce > 0).