MAP Protocol: Active Relay Chain Cross-Chain Pioneer

Author: AvatarDAO

Project Background

1. Layer 1 and Closed Islands

• Layer 1 refers to the underlying blockchain.

• Includes Ethereum, Bitcoin, Solana, Polkadot, Near, Cosmos, Aptos, Sui, etc.

• It is the main network in their respective ecosystems.

• Layer 1 can process and complete transactions on its own blockchain while having a native token for paying transaction fees.

• Ethereum is a giant, but it cannot dominate alone.

https://defillama.com/chains

• The L1 ecosystem is thriving, continuously eating into ETH's ecosystem share.

• Due to technical, ecological, and competitive reasons, each main chain acts like isolated islands, unable to communicate or transfer assets between them.

2. Cross-Chain

• Cross-chain: Interoperability between multiple chains, mainly including token exchange, token transfer, and information transfer.

• The isolated state of each chain limits the diversification of user needs and the scalability of blockchains.

• New dApps are constantly emerging, requiring asset transfers and data interoperability.

• Cross-chain technology is considered the holy grail in the blockchain field and is the key technology for achieving interoperability among thousands of chains.

• Its importance can be compared to the TCP/IP of the internet, which turned the web into the internet.

• The enormous demand of Web3.

1. The TPS required for the entire Web3 could be in the billions, and many L1s together may not be able to support it.

2. There is a strong demand to aggregate all L1s into a whole.

3. Cross-Chain Paradigms

1. Hash Time-Locked Atomic Swaps

• Simple principle.

User A generates a random password r and calculates the hash value m=hash(r), sending the m value to User B;

At the same time, User A initiates a transaction, transferring 1 BTC to User B, which is conditional on User B presenting the password r for success; otherwise, if the preset time exceeds, the transaction will automatically fail;

After seeing the transaction initiated by A, User B also initiates a transaction, transferring 10 ETH to User A, which is also conditional on User A presenting r for success;

After seeing the transaction initiated by B, User A presents the r value, allowing B's transaction to succeed and obtaining the 10 ETH transferred by B, revealing the r value;

User B also obtains the r value presented by A in the previous step, allowing A's transaction to succeed and obtaining the 1 BTC transferred by A;

If the preset time (hash time lock) exceeds, the transaction will also automatically fail;

• The hash value and time lock enable atomic transactions between both parties without intermediaries, requiring no trust assumptions, as hash operations are irreversible; knowing m does not allow one to deduce r.

• Coupled as a single event, either all succeed or all fail; there will be no situation where A's transfer to B succeeds while B's transfer to A fails.

• Both parties must be online simultaneously, strictly following the participation process; if an online trading counterpart cannot be found, they must wait.

• Transaction fees are relatively high.

• Cannot achieve token transfer and broader cross-chain information transfer.

• Often used in combination with other cross-chain technologies.

1. Multi-Party Witnesses

• The generation of witnesses may be permissioned or freely accessible.

• User trust in witnesses may come from the witnesses' own credit or from excessive collateral provided by the witnesses.

• Witnesses can be designated, rotated, or randomly selected.

• The witness model is a relatively easy-to-implement cross-chain method with strong versatility and low adaptation costs.

• If a hacker successfully breaches a witness server, they can steal all funds locked in cross-chain transactions.

• Project parties can embezzle related funds.

• The entire verification process cannot completely avoid the risk of malicious acts.

• Cross-chain bridges suffered losses of $2 billion in 2022, with projects using MPC cross-chain being the most affected.

• Mainstream cross-chain facilities like Multichain, Celer, and Axelar all use MPC.

3. Semi-Centralized Oracles

• Oracles and relayers operate independently and verify each other.

• Chainlink's Oracle submits source chain cross-chain information (receipt) to the main chain, while the relayer also submits cross-chain information (blockhash and blockreceiptsRoot) to the main chain. The main chain's transaction verification contract verifies the correspondence between the receipt submitted by the relayer and the receiptsRoot submitted by the Oracle (the order here does not correspond and needs confirmation). If verified, the receipt is considered valid and forwarded to the upper-level protocol, triggering subsequent cross-chain asset operations.

• It must be assumed that the relayer and oracle are independent, but this trust assumption cannot hold indefinitely, fundamentally ensuring that the two cannot collude maliciously.

• The relayer relies on the amount of staking for authoritative ranking; although randomly selected, they still belong to authoritative individuals, and the risk of collusion between the oracle and authoritative individuals still exists.

• At the same time, the oracle's cross-chain data feeding is not precise enough, and the degree of decentralization cannot provide cryptographic proof, leading to the possibility of third-party collusion.

• The token project is LayerZero.

• It is not absolutely decentralized.

3. Light Nodes

4.1 Light Nodes

• Refers to light clients.

• It is a smaller node that only stores block header information.

• Light nodes do not store all transactions on the chain but can verify the authenticity of messages from the source chain through block header information.

• The process is roughly as follows:

When source chain A (e.g., SOL) has a request to transmit cross-chain transaction information to target chain B (e.g., ETH), the transaction initiator submits the transaction details, block height, and SPV proof (referring to the transaction's Merkle path) to chain B;

The light node contract of chain A deployed on chain B recalculates the block header hash of the block where the transaction is located through the SPV proof;

The obtained hash value is compared with the corresponding block header hash value in the light node; if they match, it indicates that the transaction indeed occurred in that block; if not, it indicates that the transaction does not exist in that block.

4.2 Bi-Directional Anchoring Light Nodes

• Both chains are main chains, each with a consensus mechanism and native tokens, each with security guarantees.

• The relationship between the source chain and target chain is relative; both chains can serve as source chains.

• In a cross-chain message transmission event, the source party of the message is often referred to as the source chain, while the receiving party is referred to as the target chain.

• Both cross-chain parties can achieve mutual reading of each other's information by embedding each other's light nodes, which is referred to as two-way pegging.

• There are relayer groups responsible for transmitting information in both directions.

• The representative project is MAP Protocol, which achieves two-way pegging with any chain.

4.3 Subchain Bi-Directional Anchoring

• Subchains exchange information with main chains through light nodes, such as the relationship between the Polkadot mainnet and subchains, the relationship between Cosmos and subchains, and the relationship between Aurora and subchains.

• Subchains do not have their own consensus mechanism and native tokens; their security relies entirely on the main chain, exhibiting unidirectionality, while sidechains operate as independent blockchains, with the relationship between sidechains and main chains being a relative concept, exhibiting bidirectionality.

4.4 Relay Chain

• Establishing bi-directional anchoring light nodes between every two chains, the number of connections and adaptation costs will increase exponentially with the number of chains.

• Relay Chain: Establishing a relay chain that contains light nodes of all other main chains, and then establishing light nodes of that chain on each chain, connecting all other chains to the relay chain, reducing costs from n(n-1)/2 to n (n being the number of chains).

4.5 Advantages of Relay Chain Type Light Nodes

• Shared Mainnet Security

The relay solution is a variant of the bi-directional anchoring solution, sharing the security of the main chain;

By verifying transaction information through block headers, its reliability is guaranteed cryptographically; whether a transaction exists is independent of the verifier, making it completely decentralized;

The verification program of light nodes is identical to that of the source chain network, sharing the security of the source network;

Relayers cannot falsify the block headers they transmit because light node contracts can verify blocks as rigorously as full nodes, and false block headers cannot pass verification;

If malicious relayers collude, the only feasible method is to transmit a block header from a forked chain, but for a healthy network, a forked chain will not become the longest chain;

Only if the source chain or target chain itself undergoes a reorganization will it affect the security of the light node contract.

• Completely Decentralized

Unlike witnesses, relayers are controlled by contracts and are unrelated to centralization;

They do not rely on any privileged third party or authorized third party for legitimacy verification;

• Lower operational costs and a broader decentralized future

Relayers in light node-based sidechains do not need to over-collateralize like witnesses, allowing for more cross-chain anchored asset issuance at a lower cost;

• A lightweight method to quickly verify the legitimacy of a transaction across the entire ledger.

• Light nodes utilize mutual embedding of each other's light nodes for contract verification, possessing independent self-verification characteristics.

• Highly scalable, currently the most widely used cross-chain solution.

4.6 Disadvantages of Relay Chains

• Different adaptation plans must be developed based on the characteristics of different access chains, requiring proactive compatibility, which is labor-intensive.

• The security of different chains varies, involving cross-chain credit issues for different access chains to protect the overall security of the cross-chain network.

• New blockchains are emerging continuously; if a new feature access chain appears, a new adaptation plan needs to be developed.

4.7 Blueprint Formed by Relay Chains - Omnichain

• Omnichain is the future of multi-chain, providing a one-time solution to cross-chain issues.

• Truly achieving interoperability among thousands of chains.

• A certain relay chain becomes the layer 0 of the blockchain world, while other chains connect as layer 1, layer 2, etc.

• The relay chain is not just a bridge but a hub (chain hub) that, while undertaking the task of cross-chain message transmission, also needs to handle issues like message routing and timing between chains.

• dApps, protocols, and users on different main chains interact seamlessly and without awareness, enhancing user experience.

• Connecting users and assets across all blockchains, multi-chain ledgers are no longer fragmented.

• It is the best growth solution for dApps in a multi-chain coexistence pattern and is key to achieving growth in Web3.

• In an increasingly competitive multi-chain future, omnichain infrastructure may be a more important blockchain scaling solution than L2.

4.8 Dominant Relay Chains Polkadot and Cosmos

• Polkadot's parallel slots and Cosmos's Hub are typical "bi-directional anchoring" relationships, both embodying the relay idea, aiming to achieve global interconnectivity.

• Cosmos's cross-chain messaging protocol IB still relies on light node contracts built into the receiving chain for verifying cross-chain messages, while Polkadot's cross-chain messaging protocol XCMP does not use light node technology to verify the legitimacy of cross-chain messages but instead employs shared validators.

• Polkadot's relay chain and Cosmos Hub do not possess Turing completeness and cannot compile smart contracts. Polkadot created Substrate, while Cosmos created Cosmos SDK. Cross-chain SDKs require other chains to embed them at the blockchain layer, meaning that blockchains generated by other non-native chain tools like Ethereum, BNB, Klaytn, Polygon, Avax, etc., need to actively modify their underlying blockchain structure to be isomorphic with the two, and then embed the SDK into the blockchain layer to achieve cross-chain functionality. However, modifying the underlying structure is an extremely complex challenge, so currently, no thriving L1 has achieved chain interoperability with Polkadot's relay chain and Cosmos Hub.

• To achieve chain interoperability with Polkadot's relay chain, one must hand over accounting rights to the relay chain, which means security must be entrusted to the relay chain, something that other thriving L1 ecosystems cannot accept.

• For dApp developers, using Polkadot and Cosmos requires first building their own dedicated L1 and then deploying their dApp on the L1 they built. However, building one's own L1 is not the core demand of dApps; covering more users and assets is. From the perspectives of development cost, learning cost, and security, building an L1 first and then seeking cross-chain interoperability for user asset development paths is not cost-effective.

• Although Polkadot and Cosmos utilize light node (light client) cross-chain mechanisms and are very secure, overall, they seem to have built a large internal ecosystem, not performing ideally in true inter-chain interoperability and expanding the dApp ecosystem. The design structure and technical mechanisms of both make it difficult for them to achieve inter-chain interoperability with thriving blockchains like Ethereum and BNB. For dApps, while both provide convenient chain-building tools, they do not truly address the demand for user and asset coverage.

• Any main chain wanting to connect to Polkadot or Cosmos can only actively adapt.

• Currently, there is still no visible motivation or trend for compatibility between the two.

MAP Protocol Project Analysis

1. Project Introduction

• MAP Protocol's main chain Relay Chain is a relay chain, containing light nodes of all other main chains.

• It has installed MAP Protocol light nodes on its main chain.

• MAP Protocol actively pre-compiles contract layers on the main chain Relay Chain, embedding signature algorithms and hash algorithms of various thriving L1s.

• It fully connects mainstream EVM and Non-EVM chains like Ethereum/Polygon/BNB Smart Chain/Klaytn/NEAR, deploying MAP Protocol's main chain Relay Chain light nodes in the form of smart contracts on various L1s.

• By interconnecting light nodes with main chains that have installed Relay Chain light nodes, all L1s become isomorphic chains, while also achieving effective cross-chain validity verification between light nodes.

2. Project Architecture

1. Protocol Layer - Core Foundation

• Composed of MAP Relay Chain, light nodes deployed on various chains, and the inter-chain messaging program Maintainer.

• The MAP Relay Chain virtual machine layer successfully embeds the signature algorithms, hash algorithms, and Merkle Tree proofs of major L1s through pre-compiled contracts, making the MAP Relay Chain like a super language machine proficient in various languages, enabling mutual communication between chains, laying the isomorphic foundation for inter-chain communication.

• Light nodes possess independent self-verification and instant finality guarantee characteristics. Based on the isomorphic foundation of MAP Relay Chain, the cross-validation network of light nodes can have the same data language, easily deployable in the form of smart contracts to any corresponding L1, thus enabling decentralized cross-chain validity verification.

• Maintainer is an independent inter-chain messaging program responsible for updating the latest status of light nodes, writing the consensus layer block header (Validator signature) information of each chain into the light node smart contract of the origin chain on the target chain as a transaction, ensuring consistency between the light node on the target chain and the Validator information of the origin chain.

2. MOS Omnichain Service Layer

• MAP Omnichain as a Service Layer.

• Similar to Google Mobile Service for the Android ecosystem, providing full-chain development services for dApp developers.

• This layer has cross-chain asset locking smart contracts and inter-chain messaging components Messenger deployed on various blockchains, allowing developers to directly utilize this layer to establish omnichain application scenarios or further compile according to their needs, thus saving the development and learning costs of the entire chain.

• The smart contracts in this layer are all open-source components audited by CertiK, allowing dApp developers to use them directly without worrying about security and development cost issues.

3. Omnichain Application Layer

• Taking decentralized derivatives and synthetic assets as examples, both are currently constrained by the prices and quantities of assets on other chains, and accurate, timely asset data cannot be obtained through off-chain oracles, leading to poor liquidity and user experience.

• Although multi-chain deployment can solve this issue, the process is time-consuming and labor-intensive, increasing unnecessary development costs.

• By deploying on the MAP Relay Chain, decentralized derivatives and synthetic assets can obtain accurate multi-chain data from the MAP Protocol chain oracle, no longer constrained by data flow obstacles, thus easily achieving asset flow across the entire chain.

• Similar application scenarios include omnichain DID, omnichain lending, omnichain Swap, omnichain GameFi, omnichain DAO governance, omnichain tokens, and omnichain NFTs. Regardless of which L1 the main business contract of the dApp is deployed on, developers can easily build omnichain applications capable of covering all chain users and assets through MAP Protocol.

3. zk Technology Applications

• Signature verification: Merkle proof checks for specific Merkle roots, as well as hash link and cumulative work checks, are suitable for authentication via zkSNARK.

• In the construction of light nodes, it simplifies the storage of a large amount of validator group information or block headers.

• Commitments relate to the validator set (PoS) or the latest block header set (PoW), and each time the set changes, the commitment is updated.

• Using zkSNARK to prove that the change from the old commitment to the new commitment reflects valid changes in the validator set or block header set.

• The limitations imposed by zkSNARK mainly include checking whether there are enough old validators approving the new set and whether the voting weight exceeds a certain threshold.

3. Omnichain Application Examples

1. Cross-Chain Lending

• Currently, if a user has funds on chain A but wants to mine on chain B, they must go through 9 steps:

Stake on chain A -> Borrow -> Cross-chain bridge (fee) -> Exchange (fee) -> Mine on the target chain -> Exchange back (fee) -> Cross-chain back (fee) -> Repay loan -> Unstake;

• Through MAP Protocol, the user can stake on chain A and borrow, mine, repay, and unlock staking on the target chain, skipping four cross-chain bridge and exchange fees.

1. Omnichain Swap

• Omnichain Swap connects the best cross-chain DeFi protocols, allowing for token exchanges at significantly lower fees than traditional DeFi exchanges.

• Through MAP Protocol, developers can create a truly decentralized omnichain exchange, enabling users to exchange any token on any chain.

• Omnichain SWAP can also achieve omnichain aggregated exchanges by connecting the liquidity of mainstream DEXs.

• Existing AMMs can be wrapped to execute full-chain exchanges from one asset to another without modifying any existing code.

• Users will be able to swap ETH from Ethereum to Near on NEAR with just one transaction from the source chain.

• In the omnichain exchange built with MAP Protocol, users can add liquidity for multi-chain tokens in one pool, meaning providing liquidity for a pair of tokens from different chains becomes possible.

• Butter Swap is the first truly decentralized cross-chain network that allows users to swap any token on any chain and is currently in testing, soon to be launched.

1. Omnichain GameFi

• Through MAP Protocol, GameFi projects can deploy their tokens across multiple chains and allow users from other chains to efficiently and securely transfer their assets to their project's chain.

• For example, a BNB Chain GameFi project deploying its tokens on Polygon and WAX allows users from Polygon and BSC to transfer their assets to WAX via a cross-chain bridge and participate in GameFi, significantly increasing the user base.

• Another scalable way to maintain a good gaming experience is to deploy directly on the MAPO Relay Chain. Through the interoperability of MAPO Relay Chain, GameFi projects can automatically connect effectively and securely with all EVM and non-EVM chains by deploying on MAPO Relay Chain. MAPO Relay Chain will actively connect with all upcoming chains so that GameFi projects can focus on user experience without worrying about scalability and security issues.

1. On-Chain Data: On-Chain Oracles and Derivatives

• MAP Protocol achieves data cross-chain and is cultivating a brand new oracle market—on-chain oracles.

• By deploying on the MAPO Relay Chain, derivative and synthetic asset applications can easily obtain reliable multi-chain data from on-chain oracles.

5. Omnichain Governance

• Taking Aave as an example.

• As its developers state, a proposal executed on the Ethereum (ETH) network is sent to Polygon via FxPortal. The mechanism then reads Ethereum data and passes it to the Polygon network for verification. After that, the Aave cross-chain governance bridging contract receives this data, decodes it, and queues actions, waiting for a time lock to complete. The Aave cross-chain governance bridge is built in a universal way, easily adaptable to operations with any chain supporting EVM and cross-chain information transmission.

• Currently, this repository supports contract bridging with Polygon and Arbitrum. On Aave, users can submit Aave Improvement Proposals or AIPs for various features of the DeFi platform. With the interoperability of MAP Protocol with all chains, full-chain management of all EVM and heterogeneous chains can be achieved through secure cross-chain infrastructure.

5. Fungible Token and NFT Bridges

• Cross-chain bridges and cross-chain NFT bridges no longer need to establish their infrastructure or use MPC.

• Using MAPO's underlying cross-chain verification network with instant finality and the MOS application developer service package, cross-chain bridge developers can easily establish their NFT or fungible token bridging applications.

4. Project Advantages

1. Omnichain Interconnectivity, Full Network Cross-Chain

• Unlike Cosmos, Polkadot, and Aurora, MAP Relay Chain achieves isomorphism with all chains, interconnecting all L1s, rather than merely ecological isomorphic chains. It is the only omnichain infrastructure in the market that can cover all chains with the highest security.

• Through the relay chain, all fragmented public chain ledgers become a distributed ledger.

• NEAR's Rainbow Bridge, Polkadot, Cosmos IBC, and the omnichain MAP Protocol all adopt 100% Satoshi consensus and 100% mathematically proven light-client independent self-verifying cross-chain technology. However, Polkadot, Cosmos IBC, and NEAR's Rainbow Bridge cannot cover all chains, only their own ecosystems. For example, Polkadot and Cosmos IBC cannot support cross-chain transactions with heterogeneous chains like Ethereum, BNB Chain, and Polygon. The Rainbow Bridge currently can only cross Aurora (NEAR's EVM).

2. Completely Decentralized, No Privileges, 100% Satoshi Consensus Mechanism

• Light nodes, Maintainers, and Messengers mutually verify each other, ensuring the authenticity and security of cross-chain verification comprehensively, eliminating the possibility of malicious acts by Messengers and Maintainers from a mechanistic perspective. The cross-chain technology verification at the blockchain level using 100% Satoshi consensus does not rely on any off-chain data verification or any third-party privileged roles, making it a provably decentralized cross-chain mechanism.

• LayerZero includes light nodes, but this is only for same-chain verification, not cross-chain verification, and it also has ambiguous privileged roles (oracles).

3. Shared Main Chain Security

• MAP Replay Chain adopts a relay solution, ensuring security through bi-directional anchoring of light nodes. The verification programs of light nodes are identical to those of the source chain network, and the completely dual mainnet verification mechanism is guaranteed by cryptography. Unless malicious fork behavior occurs, it will not affect the security of the light node contract, making it the safest cross-chain solution to date.

3. Compatibility with EVM and Non-EVM Chains

• The relay chain has pre-built signature algorithms and hash algorithms for various public chains, enabling multi-chain expansion and linking EVM and non-EVM chains, supporting cross-chain communication and secure, seamless transfers of assets.

3. Developer-Friendly

• Compatible with almost all blockchains and supports native deployment of DApps on the relay chain.

• Based on light node (light client) cross-chain lightweight client SDK, each blockchain can directly access the underlying layer.

• Provides self-developed SDK, reducing the complexity of dApp development for developers.

• Unique design based on zero-knowledge proofs reduces the difficulty of developing heterogeneous chains while ensuring the security of cross-chain message transmission.

3. Lower Operational Costs, Broader Decentralized Future

• Relayers in light node-based sidechains do not need to over-collateralize like witnesses, allowing for more cross-chain anchored asset issuance at a lower cost.

• Optimizes data verification costs through zero-knowledge proofs (ZK) + light node (light client) cross-chain verification methods, reducing gas fees.

5. Team

• MAP Protocol was founded in 2019.

• It is a team completely dominated by a culture of geek engineers and researchers.

6. Social and Promotion

• Twitter: 106,000 followers.

• High engagement on tweets.

• Founders actively participate in various events.

• Actively and proactively collaborate with other project parties.

7. Token Economic Model

Total supply: 10 billion.

• 15% for team incentives.

• 21% belongs to Ecosystem DAO.

• 12% owned by the MAP Protocol Foundation.

• 22% owned by investors and early supporters.

• 30% for mining rewards.

8. Market Capitalization

• Market Cap: $22,342,490.

• Circulating Supply: 2,228,621,190.

• Circulation Rate: 22.3%.

• Total Market Cap: $101,348,762.

9. Token Holding Situation

10. Code Development Status

• Code development started in 2021 and has not been interrupted, with a high update frequency.

• Code reference.

• Team of 10 people.

• Version updates and iterations: 8 times.

11. Expert Evaluation

1. Bohao Tang, Chief Developer of Flow

• MAP Protocol is helping Flow build the infrastructure for omnichain application experiences, characterized by cross-chain verification without privileged roles and coverage of all EVM and non-EVM chains. We believe it can bring richer possibilities to the Flow ecosystem.

1. Professor Liu Yang, Director of the Cybersecurity Laboratory at Nanyang Technological University

• The omnichain interoperability of MAP Protocol is safer and more compatible compared to other cross-chain solutions, making it more developer-friendly. "MAP Protocol's mature, novel, and stable cross-chain design enables secure and seamless cross-chain communication and asset transfer between EVM and non-EVM chains. Compared to centralized cross-chain solutions without relay chains like Axelar and Celer, MAP Protocol's relay chain not only facilitates multi-chain architecture expansion but also avoids the risk of super administrators controlling inter-chain communication maliciously.

• Compared to the decentralized solutions of Polkadot and Cosmos using relay chains, MAP Protocol uniquely incorporates zero-knowledge proof solutions, using light clients existing in the form of smart contracts to verify inter-chain messages. This lightweight implementation not only eliminates the need for SDK embedding and structural compatibility for heterogeneous chains but also ensures the security and confidentiality of inter-chain message transmission, making it compatible with almost all blockchains and enabling interoperability.

• Most importantly, MAP Protocol's innovative cross-chain design allows dApps to be developed and natively deployed directly on the relay chain. By connecting assets across various blockchains, MAP Relay Chain becomes a key component for cross-chain asset and data interaction, with the potential to prove itself as the true future of cross-chain solutions.

12. Conclusion

• A high-quality solution for cross-chain interconnectivity (shared main chain security, decentralization).

• Full network cross-chain, omnichain interconnectivity, with broad prospects.

• The team has accumulated deep expertise over many years.

• The project is of high quality but undervalued.

References:

In-Depth Report | Connecting Islands into Continents: A Panorama of Cross-Chain Technology and Application Forms (1)
A Detailed Explanation of MAP Protocol: Provable Decentralized Omnichain Infrastructure
Why LayerZero is Considered a Pseudo-Decentralized Cross-Chain Protocol?