1. MOV Protocol
1.1 Technical Framework
MOV is a next-generation decentralized cross-chain Layer 2 value exchange protocol based on Bystack’s mainchain-sidechain architecture. Consisting 3 core modules: Value Exchange Engine Magnetic Contract (Magnet), Decentered Cross-Chain Gateway (OFMF) and Layer 2 High-speed Sidechain (Vapor), MOV is dedicated to building a heterogeneous value asset exchange and collaboration ecosystem.
The successful release of Bystack laid the foundation and product form of the MOV protocol and constructed a self-sustainable ecology while expanding the boundaries of assets of Bytom. And MOV will be more committed to an open and exogenous ecosystem, nourishing more mainstream asset dimensions and the formation of other ecosystems based on Bystack, establishing a value exchange matrix on multiple dimensions.
Figure 1 Internal and External Ecosystem of Bystack & MOV
The mainchain-sidechain architecture is commonly seen in hierarchical systems. For example, Plasma chooses one mainchain and multiple sidechains for the mainchain scaling based on the mainchain mortgage. Mainchain and sidechain are logical distinction. Mainchain, while working as a public blockchain, can be used as a platform for mapping assets on sidechain and transaction collaboration. The mainchain-sidechain logic is a reasonable business architecture design, giving more freedom and space for value exchange collaborations.
At present, gateway and sidechain-relay take the center stage of cross-chain solution while Hash-Locking is generally used to construct atomic swap in payment channels. Polkadot and Cosmos, the most famous projects in terms of sidechain-relay, are based on PoS governance. They will dominate themselves in cross-chain collaboration scenarios and have their own standard framework in development, SDK and cross-chain communication protocol. With native economic model and tokens, they aim to solve the evil-doing and incentive problems in cross-chain collaboration. Such heavy model scheme will face complex governance issues such as judging good and malicious nodes. The fluctuation of governance will affect the efficiency of cross-chain collaboration, so it is not conducive to the establishment of their respective cross-chain ecosystems in the initial stage.
In addition, the sidechain relay protocol based on smart contract is not suitable for accessing the final public blockchain (such as bitcoin), which will lead to cross-chain transaction confirmation and affect user experience. This model will also face high maintenance cost like data availability and assets expansion. The gateway mechanism is an efficient and practical mechanism that has been verified by the actual scene. The gateway plays an important role in establishing cross-chain trust endorsement, unifying cross-chain communication protocol and coordinating mainchain-sidechain transaction confirmation. In real-life scenario, cross-chain gateways will face the drawbacks of centralized operation, which leads to trust issue among cross-chain collaborations and low interoperability, which in turn affects the expansion of traffic, applications and developer ecology. Thus, creating an open low-cost standardized decentralized cross-chain gateway mechanism has become more important than ever.
There is a decentralized open gateway design in the framework of MOV protocol, which effectively solves the problem of trustless hosting and standardized access of mainstream assets in traditional cross-chain gateways, and provides efficient interoperability and traffic protocol for the cross-chain collaboration ecology of diverse assets.
As the core platform of value exchange, Vapor sidechain offers customized native magnet contract engine and decentralized oracle based on its own BUTXO model, breaking the asset-mapping-only boundary in traditional cross-chain models, establishing reasonable collaboration scenario of multiple asset value exchange. Compared to the current one-to-one matching model of the traditional decentralized exchange DEX (Decentralized Exchange), the magnetic contract can form a portfolio exchange model based on the BUTXO multi-asset atom exchange feature.
Whether it is a single DEX or a single cross-chain facility, it can only gather participants and liquidity facilities within its sphere of influence. Due to the isolation of communities, differences in infrastructure and economic models, it is impossible to build a comprehensive multi-asset value exchange market. DEX is unable to obtain liquidity support from the underlying chain and cross-chain ecology. A single cross-chain ecosystem often lacks or cannot take into account the influential liquidity conversion medium represented by market makers and DEX. However, forcing the integration of these existing facilities often results in the system not being able to operate continuously due to the irrational participants roles and the differences in economic models.
The new portfolio exchange architecture gives birth to new species and ecosystems. A prosperous value exchange ecosystem needs to have sound participation designations that can propel each other so that the entire economic system can be self-consistent and self-circulating. A superior technical framework allows all roles to perform their duties, reducing friction and adding value.
Figure 2 Ecosystem Flow Chart
MOV is open to a variety of proactive participants, such as Maker/Taker to Wallet/Exchange. These enormous and fragmented free participants form the core driving force of the ecosystem through a variety of native service frameworks (Magnet, Blockmeta, Byone, Bycoin), performing seamless interoperability with low friction and continuously contributing to its liquidity value while enjoying a convenient exchange experience. These liquidity accumulations and premiums can further back-feed and support ecosystem infrastructure builders (Vapor and Federation nodes) to complete economic replenishment and value-added efficiency.
1.3 Advantages and Features
Friendly to the public blockchain within the system. As an open ecosystem, the trustless and standardized gateways will greatly simplify the consensus cost and technology access costs of cross-chain collaboration, and back-feeding the public blockchain’s own asset flows and user traffic. This is a self-consistent ecology that aggregates the major players in the current blockchain industry through decentralized value exchange, including traders, wallet providers, digital asset custodians, public blockchain projects, liquidity providers, derivatives developers and DeFi developers etc. There may be diverse needs, such as privacy protection, onchain credit, onchain oracles, etc. Integration and support for these infrastructures will bring traders and project parties great convenience and attraction.
2. Open gateway OFMF
2.1 Open cross-chain gateway design elements
A complete cross-chain mechanism will form a good network effect and interoperability, making the integration and collaboration of diverse assets more borderless and seamless. It is a key entry point for a complex heterogeneous ecosystem, thus constructing a reasonable open cross-chain gateway protocol is a key part of the overall framework.
The core element of the cross-chain gateway is to establish a decentralized federal gateway, which means that the key ecological participants will form an alliance network driven by a reasonable economic model and business with reliable security, flexible management and decentralized power. Federation custodians is open to free election and economic governance (with the help of the node plan of the public blockchain’s own ecology), establishing a complete identity verification and reputation risk assessment mechanism. The change of custodians and incentive mechanisms must be completed under a transparent governance consensus models with a sound replacement design. Federal gateway should be decoupled from sidechain consensus nodes to avoid extreme situations where sidechains collectively do evil. Decoupled architecture facilitates sidechain changes and multi-asset extensions.
The roles of federation include Federal Custodian and Data Availability Service Provider:
(1) Federal Custodian: the manager of diverse cross-chain assets, the manager and executor of multi-signature authority, core role of the federation trustless mechanism;
(2) Data availability service provider: Provides data for federal custodians, collects, verifies and maintains legal cross-chain transaction information and events from the mainchain and sidechains, and provides multi-chain light node block header synchronization services (block headers include StateRoot for cross-chain trading status to verifier information, which can be used to verify transaction combined with Merkle proof of cross-chain trading).
(Federation governance consensus network. Taking into account of the clear definition and guarantee of separation of authority and responsibility of the federal node, signature cooperation, gateway governance, exchange rate adjustment and other operations need to be processed through the governance consensus network to ensure the transparency and efficiency of collaboration of federal nodes.)
Both of them acted as trust messengers and data messengers in a complete cross-chain collaboration. The rationality of their design is directly related to the completeness and standardization of a cross-chain gateway mechanism. A protocol or algorithm that is easy to obtain a standardized consensus is particularly important for the ecological development of blockchain, just like DeFi.
Data availability service providers are responsible for maintaining cross-chain data availability and even providing evidence of frauds. They export sound data services to federal nodes and assist federal nodes to handle cross-chain transactions securely and efficiently. Different federal nodes have the right to verify the authenticity and legitimacy of the cross-chain transaction through the synchronized block header information. After the verification, the federal nodes will cooperate to process the corresponding sidechain minting and mainchain withdrawal. To reach the threshold of co-management rights while monitoring the status receipt, data service provider record the merkle tree of the complete operation cycle and the cross-chain transaction. The following is a schematic diagram of the process of transferring assets between the Bytom mainchain and the Vapor sidechain through the two roles of the Federation.
Figure 3 Federation Workflow Chart
In addition, in a general open architecture, there are often sidechains with weak governance and asset values, which will be subject to the extreme cases like the collective malicious verifier. Such cases will affect the trust of the overall network. The role of Ranger could be introduced to prevent fraudulent certification. The Rangers are freely distributed in the network. They can secretly monitor or supervise randomly and periodically and get reward by cracking frauds.
As ranger can require re-examination of the block, in order to prevent them from doing evil and dust attacks, a certain deposit must be pledged before each block re-verification is initiated. If the gateway proves that the evidence is not true, the deposit will be confiscated. The sidechain is often accompanied by the operation of withdrawing or transferring assets on the mainchain. A dispute period (challenge period) could be introduced plus the third-party supervision mechanism so that large-value transaction could be monitored and secured. The initiator of the transfer operation needs to submit deposit. If there is no objection from the ranger during the dispute period, the transfer operation will be completed after the dispute period. If the ranger submits a valid dispute evidence, the transfer will be terminated and initiator will lose the deposit. Therefore, for those sidechains with weak governance structure, the ranger mechanism deserves serious consideration. The ranger needs to maintain complete blockchain data, monitor the generation of sidechain blocks and check the validity. It can be regarded as the upgrade version of the data availability service provider.
Cross-chain will bring better blockchain interoperability and network effects, guiding the major public blockchains to follow a more uniform protocol standard, which is possible to give birth to a common attribute protocol layer architecture. Therefore, a complete open gateway-based cross-chain protocol generally needs to meet the following four design elements:
(1) Decentralized governance of the gateway, that is, trustless cross-chain and asset custody;
(2) Verification of the authenticity of the cross-chain event, verifying the existence and confirmation of the cross-chain transaction by maintaining the light node synchronization block header;
(3) Uniform cross-chain protocol data format to ensure the atomicity and security of the entire crosschain router;
(4) Validity proof of cross-chain message, through the supervision mechanism such as ranger to prevent malicious events.
2.2 Open gateway management framework OFMF
Based on the core elements mentioned above, MOV proposes a practical collaboration framework, the Open Federation Management Framework (OFMF) which further divides Federation into three modules: cross-chain minting/burning, federal management and mainchain-sidechain communication:
(1) Cross-chain minting/burning module: The minting process connect other mainchain through standard protocol. When the mainchain transfers assets to the gateway, it creates corresponding assets on the Bytom mainchain and passes it to the Vapor sidechain through the gateway again. The burning process is reversed cycle;
(2) Federal management module: decentralized cross-chain asset co-hosting, managing the generation, storage and signing of multi-signature private keys, and coordinating between federal nodes;
(3) Mainchain-sidechain communication module: monitors cross-chain transactions between the mainchain and the sidechain for authenticity verification.
Figure 4 OFMF Modules
OFMF defines an open universal cross-chain protocol format, which is friendly to mainstream public blockchain, ensuring the security and atomicity of the entire cross-chain message routing, owning a complete governance structure and trust mechanism with integrated hot-cold and multisig custody system. Any other public blockchain ecosystem can independently access the interoperable network system in accordance with open protocol standards and access mechanisms.
OFMF is based on one mainchain and one sidechain hierarchical structure: firstly deal with the cross-chain transactions between the public blockchain and the Bytom mainchain, then map other public blockchain assets on the Bytom mainchain. After that, OFMF will handle the cross-chain interaction between the Bytom mainchain and the Vapor sidechain, setting up different logical sub-gateways through hierarchical mechanism, managing assets from different public blockchain, and define unique sidechain assets through the Bytom mainchain protocol.
Figure 5 OFMF Workflow Chart
Such architecture is friendly to the Vapor sidechain, which does not require attention to other public blockchains, and only interacts and reconciles with the Bytom mainchain, helping Vapor to focus on the value exchange on a larger scale. Although this framework will have a “multilateral” pattern and introduce additional routing, OFMF’s efficient and low-cost underlying mechanism based on Bytom will make the intermediate links smoother and more seamless.
2.3 Federation Management Module
At the core of the OFMF management architecture lies the construction of a trustless asset management system. A new joint asset escrow model or collaborative service brought about by the gradual booming cross-chain asset collaboration needs. Therefore the wallet provider and professional digital assets custodians are the major roles in the federal nodes plan. The Federal Node Campaign will set up open and transparent access and exit rules to disclose necessary certification qualifications and risk solvency abilities. At the same time, OFMF provides a professional decentralized gateway collaborative hosting service module to build a secure distributed cross-chain asset management system with the federal nodes.
Figure 6 Federation Management Modules
The Federal Management Module expects to reduce the manual operation of OFMF, further reducing system risk, improving system operation transparency, introducing professional and mature asset custody and cryptography mechanisms, establishing multi-level signature nesting and combination system, so that power can be easily distributed and scaled. Thanks to the practical application of the mature multi-sign and small-range threshold signature mechanism in the mainstream blockchain system, the federal nodes are responsible for different private and private key shares, running their respective nodes, in the threshold signature synchronization network and the multi-signal asynchronous network. By co-signing the transaction and multisig authenticity, the centralized power risk can be further prevented. Manual audit is reserved as the final step on the basis of automated collaboration.
Figure 7 Schematic Diagram of Multi-level key Management Mechanism
The whole set of collaborative hosting services consists of key management server, signature collaboration network, risk control model strategy, cross-chain interaction adaptation module, node management module, proxy service and open SDK/REST API:
(1) Key management server: It is mainly used for confidential operations such as collaborative generation, distribution, management, storage and signature of multi-sign and threshold signature keys. By setting up a private key proxy server and coordinating with the risk control strategy, confidential operations and private keys are detached from public network. The introduction of mature programmatic information management system could further ensure the security of federal node confidential information;
(2) Threshold network module: establishes a signature cooperative network between federal nodes through message queue and permission mechanism, which is a small and secure consensus network system;
(3) Cross-chain adaptation module: adapts extension of multiple currencies, be compatible with the traffic portal that has the mainstream cross-chain facilities, and connects the data service to verify signed transaction;
(4) Node management module: responsible for the replacement of federal nodes, executing the economic model, providing services such as node program health detection, behavior record confirmation, and message notification;
(5) Risk control model: base on the mature managed risk control strategy, 24-7 maintenance and monitoring and event recording to achieve separation of asset management and operation and maintenance. Guarantee digital asset security by restricting access to IP, API access control, limit speed limit, black and white list, multiple authentication, etc. It also provides more advanced risk control measures such as HSM encryption, fund collection algorithm, hot and cold separation, configuration key weight, and time control.
Custody systems are automatically adjusted for risk control to balance ease of use and security. Different combinations of access factors are set up according to different levels of risk, and the intrusion detection and prevention system detects suspicious activity and blocks potential intrusions. In addition, for a professional node partner who is a professional hosting service provider, an insurance mechanism for pre-allocating the reserve pool can be established under a certain circumstance. If an unfortunate security incident occurs, the reserve pool will be used to cover user’s loss.
3. Magnet Contract
3.1 Vapor Pro
To support the new Bystack architecture and MOV protocol, Vapor will be fully upgraded to Vapor Pro: integrated support for magnet contracts based on the BUTXO model, building a new open contract verification consensus, introducing pluggable module design, and providing onchain oracles.
Bytom’s unique BUTXO model interprets the nature of Transaction, which is the atomic exchange between different assets. The magnet contract further expands the capability and standardizes contracts of BUTXO’s asset exchange. The matrix trading pair model is introduced so that matrix swapping could be completed with just one transaction, making multi-asset matching discovery and atomic swapping easier to achieve, empowering efficient exchange engine support at the core level of MOV. However, there are still several aspects that needs improvement:
(1) Add a magnet contract template to simplify onchain transaction, mitigating blockchain size concern;
(2) Create a parsing library for the template, which facilitates the contract module, wallet module, and kernel module to expand/data read/parse the contract;
(3) Modify the consensus module, call the contract module to perform magnetic matching before signing blocks, and the matching rule is written into the consensus;
(4) Modify mempool module of the kernel to list the transactions that are not self-packaged as dust transactions;
(5) UTXO module of wallet layer: records the UTXO information of pending order that are related to wallet itself and provides query support for all transactions.
Figure 8 Magnet Contract State Transition Diagram
Open contract verification consensus
Upgrading the existing Vapor state machine consensus, natively supporting the magnetic contract algorithm rules, allowing all consensus node to participate in the block generation and the verification match of the contract transaction.
Pluggable module design
The decentralized value exchange protocol module is a “secondary module” that has a database, business logic, and interaction with the chain kernel through external interfaces. The secondary module does not affect any consensus logic of the mainchain kernel, but if the kernel is bundled with a secondary module, the kernel passes the block/transaction data to the secondary module for data validation or status update before and after completing some of the specified behaviors. By embedding multiple secondary modules in the kernel, sidechains enable pluggable DEX modules, virtual machine modules, or other enterprise-level custom business modules.
Based on self-consistent and self-driven onchain-based value exchange ecological parameters and data, MOV’s own decentralized financial oracle can be formed. The input, transformation and output of data are completely operated onchain, providing safe and reliable data service for community expansion and DeFi application prosperity.
3.2 Magnet Contract
The magnetic contract module (Magnet) is the core engine of the entire decentralized value exchange protocol. It is mainly responsible for two things: the first is to transfer the matchable UTXO to the chain kernel layer into for block generation; the second is to verify whether the matching logic of the transactions in the block meets the matching rule when verifying the block, and prevent the consensus node from doing evil in the matching process due to the conflict of interest. Both of the user’s pending orders and transaction matching are onchain contract behaviors.
Since Bystack is a one mainchain multiple sidechain model, the contract engine module will be combined with Vapor as a pluggable module and activated through softfork or voting.
The contract engine module needs to have the following general interfaces:
ChainStatus: to interact with the kernel to indicate its own data state, to ensure data consistency between the kernel and the secondary module
ValidateBlocks: to verify if the matching logic in one or more continuous block meets Magnet’s secondary consensus rules
ValidateTxs: to verify if one or more transactions meet the second consensus rule of the Magnet module
ApplyBlocks: to update the trading data of the Magnet module by parsing the block transaction data
DetachBlocks: to update the transaction data of the Magnet module by rolling back block transaction data
BeforeProposalBlock: to generate contract transactions and add to mempool before the consensus node generate block.
The core database module is added to store all pending contract transaction pairs to support the query requirements when matching transactions. The database needs to implement three functions:
Feedback on the types of all asset trading pairs
Add/delete/update trade pair information
Return all transaction pairs for the two specified assets (in ascending order)
There are two data sources for the magnetic contract when matching transaction pair: the first data source is the core database, which provides support of historical data; the second data source is the in-memory transaction pair, which provides data support of onchain transaction verification or block rollback.
Orderbook contract design, pending order trading contract is a premium version of coin-to-coin trading contract. The essence of the contract is to lock any number of assets A to exchange assets B at a specific exchange rate. There should be four constants stored inside the contract: the ID of the asset B, the exchange rate, the public key of the pending order user, and the address of the pending user for receving asset B. The contract can be solved in three modes:
All resolved: All assets in the contract A are converted into assets B and transferred to the address of the pending order user
Partial resolution: Part of the asset A in the contract is converted into asset B and transferred to the address of the pending order user. The remaining assets A are re-locked back to the contract itself (the newly generated UTXO) through the recursive contract model.
Cancel pending order: The pending order user transfers the asset A in the contract back to his own address by private key signature.
Support professional trading strategies: limit order, advanced limit order (real-time transaction residual cancellation, full transaction or cancellation), market price order (the best price of the counterparty, the best price of oneself, the best five-level real-time transaction remaining cancellation) and plan order, etc.
Finally, there are questions about transaction fees and avoiding dust attacks:
Since all trade pairs are stored on hard drive, the junk transaction pair does not run out of memory, but it will take up too much hard drive space. If there is a serious problem, you can set a consensus in the Magnet module to require a small amount of BTM fee for each pending order transaction.
Contract will be inflated if it must complete the trading fee charging. You can consider setting each of the consensus nodes to set their own matching interest rate. When the consensus node matches a trade, if the interest rate is less than one thousandth after the match, the match is abandoned.
The most obvious attack vector of Vapor is the zero transaction fee setting. Malicious attacks are mostly based on this.
4. Ecological Economic Model
In the overall ecology of MOV, six major participating roles have been clearly defined in terms of efficient value exchange. Their respective responsibilities and ecological positions have been defined. Multiple economic sources such as basic income and value-added distribution have been granted to ensure normal operation of the trading system and participant enthusiasm in the early and late stages of the ecology.
These six roles are Federation Custodian, Depositor (Staker), Trader, Voter, Consensus node (BPer), and Asset Application Operator (OPer):
4.2 Ecological Incentive and Closed Loop
The MOV ecosystem contains self-sufficient incentive mechanism. With clear economic input and economic output for each participant and a dynamic balance of cost and benefit ratios at different stages of development, the six roles closely work together to form a complete ecological community.
Incentive for Federal Custodian
Federal Custodians Open Plan – Federal custodians will be open for recruitment. Managers who become federal custodians need to have rich asset management experience, strong technical development capabilities and good branding influence.
Reward Mechanism – Earn a certain amount of fees and staking rewards by providing excellent cross-chain trading services and asset custody services.
Exit mechanism – Malicious custodians will be ordered to exit, or the federal node will be removed from the federal node after requesting to quit.
Incentive of BPer
Inheriting from the election rules and incentives of the Bystack protocol, BPer are in good operation with the official launch of the Vapor sidechain. The development of the MOV ecology will further enrich the incentive source of the consensus node. In the previous design, the incentive of the consensus node mainly come from the block reward of the sidechain. In the MOV ecology, the incentive of the consensus node comes from three parts: firstly the block reward of sidechain, secondly a share of the transaction fee, and finally the price spread of matching trades.
More incentive source will attract more institutions to participate in the consensus node campaign, and thus expand the influence and competitiveness of the ecology. The exit mechanism of the consensus node is unchanged.
Incentives for stakers, traders and voters
The incentives of the stakers are derived from the minting incentives. At the initial start-up phase, stakers are encouraged to lock multiple assets, which will be converted into staking hashrate according to a certain exchange rate. The stakers will get minting reward accordingly.
The incentives of the trader are derived from the promotion reserves. At the initial stage, traders are encouraged to trade and use exchange contract.
The incentives for voters are derived from consensus rewards, which are consistent with current incentive rules.
In summary, the centralized exchange has a single point of failure and the Achilles’ heel of asset security. In contrast, decentralized exchange DEX has a higher level of security: even if hacked, the user’s assets are still in their own wallet; there is no risk of self-stealing, no bankruptcy of the exchange. However, at present, decentralized transactions also have low efficiency in onchain transactions, onchain settlement, offchain matching and centralized third-party, etc.
Bytom team release the next-generation decentralized cross-chain Layer 2 value exchange protocol based on the BUTXO architecture. By proposing the innovative idea of “transfer to trade and matching as smart contract”, Bytom will fundamentally subvert the definition of traditional DEX, and then blur the following boundaries.
Firstly the boundary between the exchange and the wallet. The wallet is the trading exchange, there is no third party to match orders. The second is the boundary between the OTC and Exchange. The wallet is the combination of both. The third is the boundary between trading and transfers. The transfer is just a transaction of the designated counterparty. It is a specific transaction. The so-called trading is a transfer action that does not specify the counterparty. It is a BUTXO of token-to-token swap. The so-called market order is simply a special transaction that does not specify a counterparty and a transaction price.
Trading logic is nothing more than three major variables – counterparty, trading price, trading time. MOV will provide SDK for each module, offering flexible and high-speed magnet contract template with different trading variables, thus meeting DeFi’s diverse and high-level business needs. Meanwhile the system also opens its mature middleware services, especially for developers and operators in the field of liquidity, open quantitative strategy support, market maker APIs and composite interfaces to encourage the creation and enrichment of DeFi in a fair and open onchain value exchange market.