Open rualekseev opened 8 months ago
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.
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)
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
In this case, we will separately describe
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:
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:
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:
Masterchain block structure:
Shardchain state:
Masterchain state:
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:
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:
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:
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:
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).
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:
In such case, each step of the delivery of an interchain message from network A to network B will take on average:
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:
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:
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.