MESH

[rualekseev]

Abstract

This document specifies implementation of Mesh network aimed to allow connecting TVM-compatible networks on protocol level. The interchain relations mechanism will provide free flow of value and messages across several networks to ensure easy leverage of web3 applications deployed in different networks by smart contracts from each connected TVM-compatible network.

Motivation

There is a necessity to build a communication channel for smart contract interaction between independent TVM-based networks. New interchain communication mechanism must have the following traits:

• High speed of transaction processing and high throughput capacity. The interchain communication channel must provide almost the same speed and throughput as the channel for external messages delivery;
• Decentralization with no need for a trusted third party to validate interchain transactions;
• Guarantee that one interchain message is delivered exactly once;
• Asynchrony, i.e. outages of one network should not affect the operation of the others;
• Ability to be flexibly configurable, i.e. it must have mechanisms for swift connection and disconnection of new networks and for workload orchestration.

Specifications

The proposed protocol-embedded mechanism of interchain communication (Mesh network) fulfils all of the abovementioned requirements. It will offer seamless smart contract message exchange as if contracts from different networks exchanged messages within a single network.

To achieve the outlined features, the concept of the proposed Mesh network ideologically relies on the currently existing workchain-to-worckchain interaction mechanism:

• An outbound message to a smart contract deployed in workchain B appears in outbound message queue in workchain A;
• Outbound messages from workchain A are transferred to the following master block 1;
• Inbound messages appear in inbound message queue of workchain B its nodes receive master block 1;
• Once the an inbound message is processed by the recipient smart contract in workchain B, the transaction is generated;
• Transaction is recorded into the state, which is hashed and put into the following master block 2;
• As workchain A nodes receive master block 2, the outbound message is considered delivered and gets deleted from the outbound message queue of workchain A.

Each network will have a list of connected external networks. Nodes of each network connected to Mesh will broadcast and receive masterchain block parts and masterchain state parts to other networks. If a queue of interchain outbound messages is not empty, nodes broadcast the block part of shardchain block containing the messages to the recipient external network nodes. The interchain messages are picked by collators of the recipient network from the inbound message queue. Message is processed by validators of the recipient external network.

Changes in Data Structures

Implementation of Mesh network requires making changes in existing data structures with adding new entities, reviewing the collation mechanism, and introducing a new message type.

Block data structure:

• Outbound and inbound message dictionaries will be extended by interchain message type;
• New dictionaries with interchain transactional data will be added to AccountBlock;
• ValueFlow structure must will contain values of tokens sent to all of the external networks;
• Blocks will include Merkle trees updates that will be broadcasted to the nodes of external networks.

Masterchain block structure:

• ConfigParams will contain a list of connected external networks;
• Masterchain block will include the information on the last masterchain blocks committed in every connected external network:
  • External masterchain block ID, logical time of the commitment, etc;
  • Sum of received tokens since the last block commitment;
• Chain of shard block proofs will be added to ShardDescr. Every proof from the chain proves the immutability of the shard queue containing the messages to an external network.

Shardchain state:

• Will include a separate queue of outbound messages for each connected external network.

Masterchain state:

• ConfigParams will contain a list of connected external networks;
• Masterchain block will include the information on the last masterchain blocks committed in every connected external network (the same data as in masterchain block structure).

A new message type that will be added to the network will be described further in the separate section.

Network

From the network perspective, interchain messaging in proposed realization does not differ from internal messaging. Consequently, the currently existing network layer structure will be used with addition of new requests.

Direct requests to external networks will be added to the network layer:

• Request for a block part of the next master block;
• Request for a block part with a block ID;
• Request for shard state part stored in the nodes of the external network.

Virtual Machine

Virtual machine architecture will include new opcodes for working with messages from external networks or will redefine the currently existing opcodes to support interchain message processing.

Actions of message sending will be realized similarly to the current actions:

• action_send_msg#0ec3c86d
• action_set_code#ad4de08e

The virtual machine will also be reconfigured to work with interchain messages on its stack (searching and reading).

A method for reading the necessary parameters (gas price, message fee, and etc.) from an external network with its short ID will be added to the virtual machine.

Collation

Adjustments to the existing collation mechanism will preserve current guarantees for executing internal and external messages.

Execution of interchain messages is guaranteed to be performed only once in accordance with the logical time in their chain; the logical time of mesh participants will not be synchronized, i.e. every external network will have its own logical time.

No new rules for collator operations validation will be introduced. Collators will try to process as many messages as they can in the collation period restricted by the consensus time of one second. Messages will be processed according to their logical time and priority.

New message type

Сurrent TL-B message scheme does not allow adding new message types. Currently existing message types cannot be used for interchain messages.

Message format requires adding a new constructor of 1 byte in length. It will allow defining currently existing message types (will be backward compatible) and adding new ones

Changes in Network Configuration Parameters

ConfigParams will include information on external networks. Each network will be described by the following fields:

• Zero state root and file hashes (zero state identifier);
• Hardforks IDs;
• Short ID of the network (used to locate an external network);
• Connection status (Connected, Disconnected);
• Native coin global ID;
• Liquidity pool contract address;
• Absolute values to define the limits for processing messages incoming from the network. These values can include (gas, message size, number of actions, etc.);
• Emergency Guard public key;

and other service data.

Connecting a New External Network

As networks connected to Mesh have to exchange current state and last block parts with each other, all of the mesh participants must be synchronized with each other. The algorithm of connecting two external networks to each other is similar for both networks and must be performed synchronously:

• Nodes of a network add reference to an external network GlobalConfig into their configurations. Thus, nodes from one network will be able to connect with the nodes from the external network;
• The network configParams list of external networks is extended with the data about the new external network. At this point, networks still are in ‘not connected’ status;
• Networks synchronize their states with each other: nodes of each network prepare block and state parts to broadcast to nodes of other external networks;
• Once the states of both networks are synchronized, they are ready to exchange interchain messages.

External Network Disconnection

Disconnection of an external network is performed unilaterally via making changes to network ConfigParams, which means that the disconnected network cannot affect the process of its disconnection.

All the messages from the outbound message queue to the external network that is being disconnected must be processed.

Functionality of Emergency Guard will be implemented to request emergency interruption of interchain communication with a malfunctioning external network. The Emergency Guard will not be able to resume interchain communication on its own or totally disconnect an external network. In case the interchain communication has been interrupted by an Emergency Guard, interchain message exchange will be resumed by the same principle as in case of adding a new external network, i.e. via making changes in network ConfigParams.

Economic model

The economic model is developed to completely decouple the inter-network forwarding scheme from the economic issues of converting one token to another, as well as from the risks of a lack of liquidity, in which messages could become "stuck between networks".

Let's consider communication between networks A and B. Some smart contract in A wants to send tokens to B.

Liquidity pool and minting

The extra currency identifier corresponding to the native token of network B is written into the meta information about B in the global config of network A. This identifier should not be previously used. The system minter contract reads information about the identifiers of native tokens of other connected networks and uses it while minting (see below).

Conventionally, anyone can mint a certain number of tokens from network B in network A. To do this, you need to have tokens in network B and send them to the special liquidity pool. After this, in network A, send to the system minter contract a Merkle proof of transaction on the pool in network B. The minimum minted amount is limited by network B in the pull contract. It is expected that this amount is large enough to avoid overloading the mint system.

There can be exactly one liquidity pool contract for each external network.

The sum of all wrapped tokens B in network A always corresponds to the number of tokens on the pool in network B.

The minted tokens are then distributed as desired, according to any rules, exchange rates, and so on.

Messages delivery process

A smart contract in network A who wants to send a message to external network B must first ensure that he has network B tokens on his balance sheet (as an extra currency).

1. a contract in network A generates a message to network B, and adds network B tokens.
2. the sums of all tokens of all inter-network messages in all shard blocks committing to the master chain are subtracted from the global balance (actually burned). To do this, the master block does not need to enumerate all the messages - pre-calculated values are added to the value flow, it only needs to sum them up across all shards.
3. when importing messages into network B, the amount that was burned at the previous step in network A is subtracted from the balance of the corresponding network A pool. In this case, the overall balance of network B does not change, since this amount will eventually be imported from messages. The balance in the pool is guaranteed to be sufficient, since in network A exactly as much mints is received as is received in the pool.

Bounce messages impossibility.

The proposed scheme is not symmetrical, it is one-sided. In order to send liquidity back from network B to network A, it needs to buy wrapped tokens of network A in network B. The purchase operation is external to the described transfer protocol and therefore cannot be performed automatically at the protocol level. This makes it impossible to automatically send bounce messages.

Network Fees

The network fees for interchain message delivery must be higher than internal fees, as conveyance of messages between different TVM-compatible networks is much more effortful for validators. The fees for interchain message processing are gathered in sending and receiving networks separately.

Rationale

Why protocol-embedded mechanism was chosen for connecting TVM-compatible networks?

Why was a protocol-embedded mechanism chosen for connecting TVM-compatible networks?
During our studies three possible approaches to building a channel for interchain communication were considered. These are: trusted bridge, trust-minimized oracle, and protocol-embedded mechanism (Mesh network). Two of the mentioned above do not fully meet the criteria enumerated in the Motivation paragraph.

A "trusted" bridge means that the bridge operates based on trust in a centralized or semi-centralized entity. In a trusted bridge, a central or trusted entity is responsible for maintaining the bridge and ensuring the security of the assets locked in the bridge's smart contracts. This entity is also responsible for minting and burning the wrapped tokens on the second blockchain. This means that the solution for interchain communication built upon a trusted bridge cannot meet the decentralization criterion.

A "trust-minimized oracle" refers to a mechanism for providing off-chain data to smart contracts in a decentralized and secure manner, while minimizing the need to trust any single entity. An oracle generates a proof that some action indeed occurred in network A and sends this proof to network B. A smart contract in network B checks the received proof and performs an action. The algorithm described above bears no necessity to trust any third party.

To check proofs, smart contracts from network B must have current public keys of the validator nodes from network A. The keys are also delivered by the oracles. The contract that emits a transaction to another network must implement the gathering of the necessary proofs, and the code of the receiving contract must include the full proof processing logic. Such additional functionality complicates smart contract source code. Along with the sophisticated oracle infrastructure, such an approach towards building an interchain communication channel also requires processing costly transactions of proof processing.

The channel implementing the logic described above will also rely on proxy smart contracts that will facilitate processing of the proofs. Such reliance may become a bottleneck and gravely affect the throughput capacity of the interchain communication channel.

What speed of interchain message delivery is expected?

Taking in account the mechanism outlined in this proposal, we can model the time breakdown of interchain communication with the following conditions:

• Masterblocks are issued every 5 seconds;
• Packet loss is minimal;
• Both networks are not overloaded.

In such case, each step of the delivery of an interchain message from network A to network B will take on average:

• Importing a message from network A, shardblock collation – 1 second;
• Committing the shardblock to masterchain of network A – 2.5 seconds;
• Committing the masterblock from network A in network B – 2.5 seconds;
  Issuing a shardblock in network B – 1 second;
• Committing the shardblock into the masterchain of network B – 2.5 seconds.

So, the whole operation will take 9.5 seconds in the best scenario. Each step may require more time due to various causes. In the worst case, interchain message delivery may take dozens seconds, the upper boundary cannot be calculated precisely.

Why cannot workchains be used for external network communications?

All workchains of one given network share logical time (LT). Different networks, in turn, have different LT. Moreover, internal workchain messages have different priority and delivery guarantees in comparison to interchain messages.

Can Currency collection be used for non-native token transfers?

It is technically possible to use Currency collection structure for interchain transferring of non-native tokens, but it ha limitations:

• Token IDs from Currency collections of different networks would have to be strictly bound to each other;
• Liquidity pool contracts would require massive changes to adopt the of token transfers on the basis of Currency collection;
• Currently, there is no network that uses Currency collection.

What would happen if an outage occurs in one of the external networks connected to Mesh?

If masterchain of network A does not receive information of its masterblocks commits to network B, it can indicate the following:

• Network B lacks liquidity;
• There are technical problems or protocol issues.
  Generation of outbound interchain messages in network A must be halted disregarding the causes of the network B outage. It will ensure that the interchain message queue does not grow excessively. To avoid throttling of interchain message sending, applications must monitor the health of the networks and send alerts in case of liquidity shortages or excessive growth of interchain message queues.

What would happen if an old contract receives an interchain message?

Old smart contracts would not be able to work with unknown (new interchain) message type.

[Futurizt]

This assumes all TVM networks have the same block and chain structures. Which is not the case. TVM means Virtual Machine, not network or protocol rules. You assume, for example, that TVM network must have Masterchain. This is not always so. May he the protocol should be renamed to TON-based networks, not TVM based. Or changes must be made into the protocol to allow for different architectures to be able to plug in, much like Ethereum L2 does not have a single standard but rather principle of operations.

[EmelyanenkoK]

Seems it will be more straightforward to implement proper lite-clients on smart contract level rather than make something deeply ingrained into TVM/network config.
From theoretical perspective the task is quite simple:
on side A

1. get initial validator set for some epoch in network B
2. if you (user) need to send message B->A, make this message an external-out message in network B
3. wait till transaction will be finalized
4. get proofs of tx inclusion into shardblock committed to some masterchain block
5. get signatures for this masterchain block
6. provide this data to checker smart-contract on chain A: this smart contract check proofs and make corresponding actions
7. sync validators on epoch change

Since TVM is very friendly to BOCs and bridge is symmetric, such TON teleport will be relatively easy to implement. Seems that such approach is more flexible and doesn't require any approval from validators (network/tvm updates, maintaining compatibility, etc)

[rualekseev]

This assumes all TVM networks have the same block and chain structures. Which is not the case. TVM means Virtual Machine, not network or protocol rules. You assume, for example, that TVM network must have Masterchain. This is not always so. May he the protocol should be renamed to TON-based networks, not TVM based. Or changes must be made into the protocol to allow for different architectures to be able to plug in, much like Ethereum L2 does not have a single standard but rather principle of operations.

good comment.
I will review the terminology used to ensure it reflects the proposal more accurately.

The document describes the interaction of two networks based on an everscale node
It includes the following top-level descriptions of changes to

• network configurations
• message format on the network
• vm

In this case, we will separately describe

• structure of the sent and received block
• structure of messages in a block
• communication protocol.