MGC TOKEN technical explanation —— High performance support

MGC Token high performance support
MGC TOKEN is committed to building a high-performance blockchain that supports cross-chain protocols - MGC TOKENChain, which supports the seamless transfer of various cryptocurrencies (such as Bitcoin, Ethereum, EOS) between parties. MGC TOKEN will lay the foundation for a dynamic blockchain industry that will no longer be affected by incompatible agreements.
At the same time, MGC TOKEN created the TPOS (SuperProofofStake)+POW+DPOS consensus mechanism: TPOS (SuperProofofStake)+POW+DPOS consensus mechanism enabled MGC TOKEN to reach the TPS level of the DPOS project, and combined with cross-chain nodes to ensure MGC TOKENChain multi-asset support Efficiency and safety.
MGC TOKEN will create the necessary infrastructure to incubate a DAPP ecosystem and leverage the communication efficiency and convenience of cross-chain technology. At the same time, in order to attract DAPP developers, we will use a comprehensive certificate economy model to stimulate the development of DAPP.
Main function overview
MGC TOKEN is based on a plug-in architecture that makes it easy to update and add new features. The MGC TOKEN ecosystem contains the following core components and key terms:
DAPP (decentralized application)
DAPP’s back-end code runs on a P2P distributed network, unlike the APP back-end code running on a centralized server.
dBTC/dETH/dEOS (debit BTC/ETH/EOS)
The form of mapped assets used on MGC TOKENChain. In this context, debit refers to the credit corresponding to the balance of the assets in the escrow account.
MGC TOKENChain The MGC TOKEN backbone, which stores transactions and other data on blocks, interconnected by timestamps and hashes in chronological order.
MGC TOKENWallet
The MGC TOKEN chain wallet shows the corresponding assets owned by the wallet holder on MGC TOKENChain. The MGC TOKEN wallet will save the MGC TOKEN token, map assets and other tokens issued based on MGC TOKENChain.
LSP (listening server program)
The listening module on the MGC TOKEN node continuously monitors transactions between other assets outside the MGC TOKENChain chain and the multi-signature managed wallet, MSE, to provide proof of the verification of the out-of-band transaction.
Mapping assets
Other supported blockchains are mapped to assets on MGC TOKENChain. They are in the form of debits corresponding to the amount in the MSE wallet and are displayed as dBTC/dETH/dEOS in the MGC TOKENWallet.
MASC (Mapped Asset Smart Contract)
A smart contract that controls the creation, movement, and preservation of mapped assets.
Master Wallet
A multi-chain wallet app that serves the main chain MGC TOKENChain and supports other assets, making it easier for users to manage multiple assets.
Meridians Plugin
Integrated cross-chain communication, out-of-band monitoring, transaction verification and other cross-chain related, help nodes to provide a secure, reliable and complete cross-chain service plug-in, is part of the MGC TOKEN client.
MSE Wallet (Multi-Signed Managed Wallet)
When the user deposits funds for the MGC TOKENChain DAPP, these extra-chain wallets for depositing funds are hosted. When users need to withdraw, only the multi-signature certification can be used to transfer funds to ensure the security of all relevant parties in the ecosystem.
Multi-signature module
A module on the node that coordinates the multi-signature verification process for cross-chain nodes.

node
Contains all records of MGC TOKENChain, including super nodes, cross-chain nodes, and candidate nodes.
Chain assets
The assets on the chain are assets on MGC TOKENChain, such as MGC TOKEN tokens, other assets issued based on MGC TOKENChain, and mapped assets (dBTC/dETH/dEOS, etc.).
Out-of-chain assets
Out-of-chain assets are assets that are not part of MGC TOKENChain, such as BTC/ETH/EOS.
DPOS (cross-chain entrusted equity certificate)
The improved entrusted equity certification mechanism supports safe and efficient multi-asset cross-chaining.
MGC TOKEN scheme design
To meet the needs of users and developers, MGC TOKENChain will be designed as a high-performance underlying operating system with multi-asset cross-chain protocols and smart contracts with Turing completeness. The overall structure is shown below:

The design process is as follows:

1. With the multi-chain chain wallet designed by MGC TOKENChain, the user can import the wallet in which the assets to be recharged are located (proven the ownership of the assets). The import process will be completely decentralized and the user private key will not be logged during this process.
2. Recharge the corresponding multi-signature managed wallet via the imported MGC, ETH or other supported wallet.
3. The supernode on the MGC TOKENChain will listen to the refill transaction via the cross-chain protocol and invoke the map asset contract.
4. After the contract is successfully executed and irreversible, the mapped asset contract will transfer the corresponding mapped asset to the user’s MGC TOKEN wallet.
5. Users can use these mapped assets to use DAPP based on MGC TOKENChain.
6. When the usage is over, the user can recharge the mapped assets back to the mapped asset account to obtain the out-of-band asset withdrawal authority.
7. When the privilege is met, the attestation node will initiate a cash withdrawal proposal. When more than 2/3 of the cross-chain nodes are signed, the out-of-chain asset will return the address that the user has extracted.

In order to meet these needs, we have made major breakthroughs in five key points.
1.Meridians plugin (cross-chain protocol plugin)
When designing cross-chain agreements, we found that transaction settlement was affected by differences in underlying performance and time of release. For example, BTC takes nearly an hour to get confirmation for six blocks. If the user directly develops DAPP based on BTC, its efficiency will lag behind the efficiency of DAPP based on EOS (EOS has a block time of 0.5 seconds).
This is unacceptable to developers and users, so we introduced a multi-signature managed wallet mechanism that helps users lock out-of-chain assets through cross-chain plugins and issue equal amounts of mapped assets for MGC TOKEN wallets during the lock-in period. (such as DBTC, DETH). Based on the mapping assets of MGC TOKENChain, users will be able to use DAPP on the chain more conveniently, faster and more equitably.
DAPP developers can use the MGC TOKENChain smart contract protocol that supports multi-chain assets, and users will be able to access DAPPs on the chain using assets other than MGC TOKEN.
In order to improve the efficiency of system iteration, MGC TOKENChain adopts a plug-in organizational structure. On this basis, we have added a cross-chain plugin to help users use MGC TOKENChain-based DAPP with out-of-chain assets.
Cross-chain assets will achieve the following functions:

1. Creation of MSE Wallet
2. Out-of-chain asset transfer (withdrawal)
   MSE Wallet (multi-signature managed wallet) example:
   Bitcoin
   P2SH (Pay-to-Script Hash) was introduced in 2012 as a new, powerful type of transaction that greatly simplifies complex trading scripts. It is another payment method. The output of the constructed transaction is not a script, but a script HASH value (a string of characters starting with 3). The input when unlocking needs to provide the script at the same time.
   Code (HASH value must correspond to the front) and the required signature:
   
   Byzantine Consensus of MSE Wallet BTC:
3. Node1 initiates a withdrawal request and calls the withdrawal function of this plugin.
4. The withdrawal function constructs the transaction and signs it with its own private key.
5. The withdrawal function internally initiates a link to this plugin in the other supernodes and asks them to sign the transaction.
6. This plugin in other nodes will verify the validity of this transaction to the listener plugin in its own node, and if it is legal, sign and return.
7. Node1 has collected enough signatures to broadcast the transaction.

ETH
The use of smart contracts to achieve escrow accounts, the main design ideas are as follows:

1. The contract stores the addresses of 21 managers and stipulates that only the manager can call the contract.
2. The contract provides a mechanism for achieving Byzantine consensus: when a manager invokes a function in the contract that requires consensus (eg, transfer, change Owner), a proposal number (HASH) is generated based on the information provided, and The counter is set to 1, and then exits; subsequent managers continue to call (providing the same information, accounting for the same proposal number), the counter is accumulated, and then exits; when the threshold is added to the threshold, the call is valid and the calling function is started.
3. Provide functions such as changing, adding, removing managers, and changing Byzantine consensus thresholds.
   Engineering implementation, contract code development and deployment using the truffle framework, does not involve subsequent client code.
   Subsequent interaction with the contract, using the community open source ethereumjs-tx and keythereum function library to build transaction information, and then send the transaction to the chain through a well-known gateway.
   Byzantine Consensus of MSE Wallet ETH:
4. Node1 initiates a withdrawal request and calls the withdrawal function of this plugin.
5. The withdrawal function initiates a transaction that invokes the Ethereum contract account withdrawal function.
6. The withdrawal function internally initiates a link to this plugin in the other supernodes, requesting that they also initiate the same call.
7. This plugin in other nodes will verify the validity of this transaction to the listener plugin in its own node, and if it is legal, it will initiate the call.
8. The Ethereum contract collected enough calls to execute the transaction.
   EOS
   Using EOS’s own account permission mechanism and EOS’s own eosio.msig implementation, the main ideas are as follows:
   EOS account system: Each account of EOS has an owner permission (maximum) and active permission (except that the owner cannot be changed with the owner).
   For multi-signature accounts, the owner and active permissions of an account jack are granted to alice and bob respectively, that is, account transfer (requires active permission) requires alice and bob to jointly license.
   
   Byzantine Consensus of MSE Wallet EOS:
9. Node1 initiates a withdrawal request and calls the withdrawal function of this plugin.
10. The withdrawal function calls the eosio.msig contract account on the EOS chain, initiates a withdrawal proposal, specifies the list of authorized accounts required for the proposal, and the transaction information (cash-out) that is specifically executed after the consensus is reached.
11. The withdrawal function internally initiates a link to this plugin in the other supernodes, informs the proposal name, and asks them to agree to the proposal.
12. This plugin in other nodes will check the transaction to be executed on the EOS chain and verify the legality of the transaction to the listener plugin in its own node. If it is legal, it agrees with the proposal.
13. Node1 keeps checking the status of the proposal. If the consent is sufficient, the transaction will be executed. Otherwise, the withdrawal will be announced after an expiration time.

The implementation of the project uses the function library provided by the community open source eosjs to build the transaction data, and sends the rpc call to the well-known super node in the community (the call selection here is not mandatory, the super node and the certification node of MGC TOKENChain can choose to call other The out-of-chain node or self-deployment EOS trustee node) broadcasts the transaction to the chain.
2.MGC TOKENWallet (multi-chain chain wallet)
When a large number of users use extra-chain assets to recharge these multi-signature managed wallets, there may be problems that cannot accurately determine the source of wallet recharge.
Therefore, in order to improve the user experience and convenience of MGC TOKENChain, we designed a decentralized wallet that supports multiple blockchain assets, and supports other project wallets to be bundled with MGC TOKEN wallet. In other words, users can use the MGC TOKENWallet to use the high-quality DAPP developed on the MGC TOKENChain chain with extra-chain assets such as BTC and ETH.
3.DPOS (cross-chain consensus mechanism)
However, how to maintain the security of these managed wallets? We have added a new dimension to the high-performance TPOS (SuperProofofStake) + POW + DPOS consensus mechanism - cross-chain node proof mechanism.
The cross-chain node is voted by all MGC TOKEN holders, and the 21 cross-chain nodes with the highest ticket rate will become multi-signature managed wallets.
· In order to prevent evil, cross-chain nodes must lock the equivalent value of MGC TOKEN;
· In order to ensure the stability of system operation and maintenance, cross-chain nodes must receive rewards in stages after they complete maintenance tasks.
Thus, there are three types of nodes on MGC TOKENChain:
Anchor Nodes
The MGC TOKEN holders of the whole network are elected through the DPOS consensus mechanism, and a total of 21 super nodes will be responsible for the block, with a block rate of 0.5 seconds. The SuperNode provides bandwidth and log storage (disk), computing power, and compute storage (CPU) and state storage (RAM) for the entire network. The pass holder can vote for the super node every cycle (about one minute).
Alternative nodes (Candidate Nodes)
An alternate node refers to a node participating in a super node election, including a super node, a cross-chain node, and a node that is not selected as a super node. Alternate nodes are always on standby and are ready to be replenished when a supernode or cross-chain node fails.
Cross-chain Validators
Manage multi-signal hosting accounts by maintaining the security of multi-signal-hosted MSE wallets, ensuring that out-of-chain assets are fully aligned with the wallet on the chain. The first cross-chain node will be the super node selected in the first round of voting, and the election of the cross-chain node will be held every three months.
4. Inter-chain asset replenishment withdrawal and interaction with the underlying chain
Then, in the specific recharge and embody operation logic, how do the nodes of the underlying chain divide and work together?
The underlying chain monitors the process of recharging the assets outside the chain:

1. The user sends a refill transaction to the escrow account;
2. When the node is in the block state, the LSP program deployed on the node queries the trusted block browser for the transaction recharge record of the escrow account every 0.5 seconds, and the cache is local;
3. The LSP program queries the database on the node to determine whether the refill record has been initiated, and tells the LSP whether the transaction was initiated.
4. If the transaction has been initiated, it is deleted from the local cache; if it has not been initiated, the LSP program initiates a token transaction to the issuing contract.
   
   The underlying chain verifies the legality of the request for the withdrawal of coins
5. The user initiates mapping of the asset management contract to recharge the mapped asset, and the BP receives the refill request through the interceptor;
6. The super node receives the user’s request for withdrawing money (indicating that the user maps the asset to the mapped asset management contract;
7. According to the type of the user’s coin, the super node detects the out-of-chain asset wallet bound by the user MGC TOKEN wallet;
8. If the verification fails, discard the request for the withdrawal of the coin;
   If the verification is successful, the multi-signature module (maintained by the cross-chain node) sends a request for the withdrawal of money, and the multi-signature module initiates a real digital currency transaction to the outside of the chain, and the cross-chain node multi-signs the transaction;
   5.After the multi-signature is successful, the managed wallet is transferred to the user and the user reclaims the assets outside the chain.
   
   5.MASC (Map Asset Contract)
   According to the above process, the recharging and emulation of the client is mainly to interact with the contract of the mapped asset. Therefore, MGC TOKENChain needs to deploy MASC internally to complete two main functions.
   
   5.1 Issuing Map Assets
   The tokens for BTC, ETH and EOS are mainly distributed in the form of tokens on MGC TOKENChain.
   The implementation process is as follows:
9. After the creation of the creation block, the first block node creates a system account through the system contract MGC TOKEN;
10. The first block node calls the MGC TOKEN contract to issue the same amount of anchor tokens DBTC, DETH and DEOS;
11. All SuperNodes have active permissions on the anchor token.
    5.2 Transferring Mapping Assets to User’s MGC TOKEN Address
    Taking the recharge BTC as an example, the user refill operation implementation process is:
12. The user recharges 10 BTCs to the MGC TOKEN wallet through the MasterWallet;
13. BP will listen to the 10 BTC transaction information and its own information in the form of action, triggering the currency contract to call the bpTransfer interface to form a transaction Transaction;
14. After the Transaction transaction is broadcast, when the encapsulated block becomes irreversible, the BP triggers the transfer contract transfer to the user’s MGC TOKEN address to the same amount of DBTC.