Map Protocol: Building an Omnichain Protocol for the Application layer?
The Evolution of Cross Chain Communication
As the number of blockchains grew, the problem of transferring tokens and data between chains has become an important sector since no chain has yet emerged the clear winner either in TVL or niche. As a result, while being one crypto community, users, liquidity and dev skills are fragmented and unable to speak with each other freely. To use some large words here, a multichain world needs interoperability and composability across chains. Native tokens need to be swapped and smart contracts need to be able to talk to each other even if they are operating on different chains. Bridges have enabled communication between chains but with certain trade-offs like security, trust and centralization. They also require expertise, time and cost to use. Just like in real life, travelling between countries require passport, foreign currency and airfare for which you pay a travel agent. We have seen solutions to this outside of bridges. Blockchain ecosystems like Cosmos, AVAX and Polkadot ecosystems using subnets and relay-/parachains, but that is targeting chain builders and not applications. For end users and dapp builders, their time, liquidity and options are still fragmented.
Fast forward to today though, and what we are seeing now is a new type of tech, that is creating solutions directly targeting applications, and that’s ultimately where the users and the utility live. The idea is simple, in that the protocol layer itself is integrated across chains so the applications don’t have to.
Welcome to a world where applications can be built on protocols that allow cross chain communication from day 1.
The MAP Protocol – For Omnichain Apps
Source: MAP
MAP was founded in 2019, by a team of technologists and cryptographers. With MAP, there is no oracle, no Multisig/MPC validators, or any other third-party as trusted agent. Instead, MAP has built infrastructure that can truly verify each transaction and integrate in a way that allows various chains to communicate securely using light clients, aka Simplified Payment Verification as described in the Bitcoin whitepaper. Light client technology has stood the test of time in the industry and is widely adopted by Ethereum, Cosmos, Polkadot and lots of other major public chains. Doing this is no small feat and has required deploying light clients on every blockchain that is integrated into its network and the team today is on its way to integrate every major chain out there.
Source: MAP
Deploying Light Clients on Every Chain
For those that don’t know what a light client is, if you think of blockchain as countries, the light client is acting as a customs control in each country. Light clients in MAP Protocol are responsible for providing the correct block header and checking that a given block header is correct. The validation of block headers for almost all blockchains requires very limited but critical information so that the required information can be stored inside a smart contract and the validation can be expressed in the same contract. In this way, as long as the light client is correctly initialized, then the light client itself would be “smart” enough to validate block headers and correctly update its internal state. In this way, MAP Protocol can achieve “verification finality” for all cross-chain transactions that cannot be done by other cross-chain solutions in the market today.
MAP Relay Chain Works as the Hub for the Omnichain Network
MAP Protocol also built their own PoS layer 1 called MAP Relay Chain, where they have extended their own EVM layer with innovative engineering. MAP integrates each chain’s consensus logic, its hashing/signing algorithms, the verification process and a lot of other chain specific data structures. It requires a tremendous amount of work and expertise to understand the consensus and algorithms of each chain. For applications that want to develop cross chain, especially heterogeneously beyond EVM, this is a NO GO from a cost-benefit point of view, but MAP does it for you so you don’t have to.
Gas Optimized
Another major hurdle MAP has cleared is the gas cost of operating all the cross-chain communication, and verification that needs to happen for you to send generalized information across. When the team finished MAP v1 in 2020, the gas costs were prohibitive. In order to reduce the gas cost in MAP v2, the team embedded different signing algorithms, hashing algorithms, mining algorithms and Merkle proof verification, in the form of pre-compiled smart contracts into MAP Relay Chain’s EVM layer.
This is no small feat. All in all, they’ve spent almost 4 years accomplishing all this and they are now getting close to launch right as the now popularized narrative around omnichain is emerging. The MAP team is also conducting R&D on zk-SNARK technology, further optimizing MAP Protocol to toward reducing cross-chain gas fees to a minimum.
How Does It work?
Firstly, we’ll just introduce some easy terminology so the below example of a token transfer can be easily understood. Don’t get intimidated by the diagrams, we’ll be using plain English to explain it all.
The Protocol Layer
Source: Map
At the bottom is the protocol layer, and here you’ll find the MAP Relay Chain, where light clients of each target chain are deployed and has deployed MAP’s light client on each connected chain. To have a cross-chain application you essentially need each chain to know what is happening on the other chains, and be sure that that information is valid. On this layer, Maintainers update the status of the Light-client deployed on the target chain so that the verification network can run smoothly. Light-clients have a self-verification mechanism so the light client will not accept invalid block headers submitted by any malicious Maintainer.
The MCS Layer
Source: Map
On top of that sits the MCS layer, this is where all the information that is being transferred sits. Here you find data and asset vault smart contracts. MAP enables generalized data transfer, which means that you can transfer any kind of information, not just tokens. Any token transfers are stored in vaults and data transfers are stored in ‘data’. Messengers are an independent inter-chain programs and are incentivized and rewarded to manage transmission of the information, build proofs and prepay gas fees. Anyone can become a Messenger in MAP Protocol. As long as the Messenger is honest while operating between chains, all cross-chain transaction messages of the dApp can be transferred. Malicious attacks by Messengers will not cause any loss of assets and simply result in invalidity of verification on the MAP Protocol Layer. Malicious actors will lose staked tokens.
The Application Layer
Source: Map
Lastly there is the application layer. This is where the applications sit. DApps do not need to deploy their main smart contract on MAP Relay Chain in order to access to MAP’s omnichain network. MAP will issue a suite of SDKs for dApps to integrate easier. For example, a project called Barter Network (@BarterNetworkio) is building an omnichain payment solution powered by MAP Protocol. There are also teams building an omnichain wallet, and an omnichain ENS services on MAP right now.
Let’s Bring in Alice and Track a Token Transfer Through MAP
Let’s say Alice wants to bridge 100 $XYZ token from Ethereum to NEAR – here is the workflow.
1. Alice will lock the 100 $XYZ to the MAP on-chain Vault on Ethereum
a) The Vault will emit a lock event.
b) The Messenger listens to the lock event and at the same time extract proof from Ethereum Network, specifically, checking the status of the transaction.
c) The messenger transfers the event message along with the proof to the Vault on MAP Relay Chain.
d) At the moment when Alice’s lock transaction becomes successful, which means there is a new block on Ethereum that contains Alice’s transaction, the Maintainer will notice there is a new block created and update the light client of Ethereum. the Light client of Ethereum on MAP Relay chain now contains the new block header and allows it to prove Alice did lock 100 $XYZ.
e) The Vault on MAP Relay Chain receives the message, verifies it against Ethereum’s light client.
f) If verified successfully, it does a mint and burn.
g) The Messenger between MAP and NEAR listens to the burn event, and extract proof on the MAP Relay Chain.
h) Transfer the message and proof to the Vault on NEAR.
i) The Vault on NEAR verifies the message against the light client on the MAP Relay Chain.
2. If verified successfully, it mints 100 $ nXYZ (minus transaction costs) to Alice’s NEAR address.
The Omnichain Landscape
Source: Map
The reason we wanted to write this article was to highlight the work the MAP team has been doing to create a really solid omnichain protocol. Constructing these light clients and pre embedded smart contracts and integrating them across both EVM and non EVM chains, requires a tremendous amount of work. Meanwhile, MAP Protocol is 100% open source and pursues security finality for cross-chain communication. There are other solutions on the market too, Layerzero for example. Firstly, LayerZero’s basecode is not open-source; secondly, LayerZero is functional only when both the oracle (Chainlink) and relayer operate independently and properly. The design itself is vulnerable to collusion risk. Whilst, we do see this as a viable solution as well and with the backing it has, it is no surprise that LayerZero is able to roll out an aggressive and fast go-to- market strategy. With that said, it is important to highlight the design of the MAP Protocol because this would be what we would call the “no short cut” way of building things. Ultimately, this stems from the fact that the MAP team comes from deep understanding of cryptography and blockchain. Without that expertise, it wouldn’t have been possible to build infrastructure like this in such a short period of time.
What the future holds nobody knows, but it is always worth highlighting important technology like MAP because it teaches us the fundamental building blocks of blockchain and showcases what kind of architecture is needed to solve one of the most pressing issues in Web3 today.
