Nominating MAP Protocol for UNI Cross-Chain Deployment
Hi all, MAP Protocol (MAPO) here. Built on Light-client & ZK technology, MAP Protocol is an interoperable omnichain layer for Web3 which enables 100% Nakamoto Style cross-chain communication with zero privileged roles. MAP Protocol can connect both EVMs and non-EVMs; it has now connected to Ethereum, BNB Chain, Polygon, and NEAR and will soon connect to Cosmos Hub, PlatON, Klytan, and other major EVM & Non-EVMs.
We believe a multi-bridge agonistic solution will be a win-win for all parties involved and especially for UNI members. With our innovative light client and ZK cross-chain solution, we genuinely hope MAPO could be part of the effort and solution to empower UniSwap to grow with greater security and interoperability.
Below are our answers to the 15 questions.
1. List 3 succinct reasons why you believe your bridge/solution would best serve Uniswap governance.
1. The level of cross-chain decentralization and security
Popular cross-chain solutions, namely MPC, Oracle + Relayer, and Light client, have sacrificed decentralization in some way or another, but MAP Protocol has kept the integrity of decentralization and security.
Specifically, in an MPC cross-chain solution, the whole verification process’s security rests in the hands of a few selected entities, which is a centralized way for verification and already contributed to several cross-chain hacks such as Ronin Bridge and Harmony Bridge. Oracle + Relayer cross-chain solution eliminates privileged parties from the verification process but cannot avoid the collusion risk between oracle and relayer.
However, MAP Protocol’s light client and ZK cross-chain verification mechanism can eliminate privileged roles and collusion risks from the cross-chain verification process because light clients used for cross-chain verification has the self-verifiable capability; the whole cross-chain verification process can be fully on-chain in a truly decentralized manner, no centralized or privileged entities involved.
With the same adherence to decentralization, we believe our cross-chain solution will be the most suitable one for retaining decentralization and keeping cross-chain space secure.
2. Full coverage for EVMs and Non-EVMs
Unlike most cross-chain solutions that only support EVM cross-chain or one-way cross-chain, MAP Protocol is able to connect both EVMs and Non-EVMs. This is because MAP Protocol can innovatively embed each destination chain’s algorithm as pre-compiled contracts to facilitate light-client deployments on MAPO Relay Chain. MAP Protocol started connecting to Cosmos Hub last month. Once it has completed wrapping light clients with Cosmos IBC standards and enters the testing phase, Cosmos inter-chain network can technically connect with other chains in a fully decentralized way. This will mark MAP Protocol to be the first cross-chain solution that allows Cosmos inter-chain network to communicate with other chains with light client technology.
With the growth of Web3 in general and the increase of users on other chains, UNI may consider deploying on other EVM and Non-EVM chains in the future to tap into more users and onboard them to the UNI community. MAPO’s extendability and full-chain coverage ability can help UNI in the long term to achieve permissionless growth.
3. Continuous technical innovation
Innovation is at the core of MAP Protocol. We were the first and only cross-chain solution that achieves truly trustless communication in the cross-chain space with full-chain connectivity. Up till now, we’ve connected to Ethereum, Polygon, BNB Chain, and NEAR, and will soon connect to Cosmos Hub, Klytan, and Avalanche.
This full-chain utility supports data and messaging cross-chain as well. Most recently, we helped CATASTROPHY, an NFT Multipass, to allow CATASTROPHY holders seamlessly access their BUIDL benefits and unlock various tools across multiple blockchains and platforms without any restrictions. We have also innovatively utilized ZK technology for cross-chain verification. MAPO is working on applying the most advanced ZK to bring down the on-chain gas fees and further increase the efficiency of cross-chain communication.
2. How long has the system been running on mainnet?
MAP Protocol has launched Mainnet since August 2022. You can access MAPO Mainnet via this link https://maposcan.io/
3. How much value has the system secured? (Current TVL, total transaction volume)
As MAP Protocol was only launched early this year, the current total transaction volume is around $529,850 for now.
4. Provide a background on your team.
With the mission of constructing a cross-chain peer-to-peer e-cash payment system infrastructure, a team of experienced blockchain research experts, smart contract developers, and bottom-layer blockchain engineering experts came together and started to build MAPO in 2019.
After almost four years of full-stack development effort, MAP Protocol is now contributed by a group of distributed team members. Core members are based in the US, Singapore, South Korea, Hong Kong, and Dubai. MAP Protocol has around 20 to 40 full-time members. With technical innovation being the core focus, 80% to 90% of our core team members are developers.
The technical team is experienced in blockchain research and development and has joined MAP Protocol’s endeavor since day one. Phil Lau, MAP Protocol’s CTO, is a member of IEEE Computer Society Blockchain and Distributed Ledgers Committee Technical Board, and Frank Wen, MAP Protocol’s chief scientist, is an expert in applied cryptography and a Core developer of Bitcoin Cash (PoW).
5. Please link your developer documentation.
- MAP Protocol Docs: https://docs.mapprotocol.io/
- MAP Protocol GitHub: https://github.com/mapprotocol
6. Does the bridge support arbitrary message passing?
Yes, as an omnichain infrastructure, MAP Protocol supports any cross-chain message passing; thus, any events on Ethereum can be passed to the destination chain in a trustless way.
7. Has the current deployed bridge code been audited? By a third party? What attack vectors and vulnerabilities were identified, if any? Have the identified vulnerabilities been remedied?
Yes, MAP Protocol has completed comprehensive audits on all products. The audit report is available here https://www.certik.com/projects/map-protocol. The issues identified in the audits are generally low in terms of severity and mainly have to do with the hash-to-point algorithms of the compiled signatures in the MAPO Relay Chain. Now, all vulnerabilities identified in the audits have been fixed and reviewed.
Cross-chain bridges have been the NO.1 target for hackers in recent years, which is why MAP Protocol puts security as one of the top priorities. MAP Protocol has partnered with world-leading third-party code auditing firms to conduct exhaustive auditing of any important updates of our codes.
8. Is there a bug bounty program?
Our bug bounty program is in the final stage of implementation. To ensure the bug bounty program can run smoothly without being spammy, we’re working internally to refine the designs and mechanism of the program.
9. List ANY portion of the functional bridge that is upgradeable and explain how the upgrade process works.
Yes, MAP Protocol’s contracts are upgradeable. The ability to upgrade is controlled by an MPC contract, but we will change the MPC contract to on-chain governance on MAPO Relay Chain for greater decentralization and security.
10. Do any contracts have an owner or owner-like entity? If so, what can the owner do?
If contracts include bridge functionality, then the contracts of Butter will be included, which does have an owner. The owner of Butter’s smart contracts is an MPC contract, where the owner can set the types of assets that the bridge can support and the transaction fees.
Note: Butter is an omnichain solution built upon MAP Protocol for secure and seamless asset movement.
11. What is the security model of the bridge? Please describe the security model for the current implementation of the bridge. What trust assumptions are you making?
Cross-chain communication enabled by MAP Protocol is based on light clients, which is implemented via cryptography. Our cross-chain solution aligns with Nakamato’s philosophy of decentralization, where no trusted third parties engage in the verification process.
MAP Protocol’s light clients are built into the chain or deployed to the chain as a smart contracts to update and save the validators’ information of MAPO blockchain periodically and to verify the proof generated by MAPO blockchain. The light client follows these steps to verify the proof data:
- Compute the epoch number of the block header and get the validators record by epoch number. If no record exists, an error is returned.
- Use the validators to verify the ecdsa signature of the block header, and use validator and the aggregated G2 public key to verify the BLS signature of the block header. This proves the validity of the block header. If verification fails, an error is returned.
- All the receipts hashes in a MAPO block construct a Merkle Patricia Tree, and the tree root is recorded in the block header. The light client retrieves the tree leaf through the tree root from block header, the key index, and the proof in the proof data. Then it checks whether the tree leaf equals the hash of the receipt included in the proof data. If not, an error is returned.
If all the above verifications pass, the proof data is proven to be valid.
Take Chain A to Chain B communication as an example. The block header information of chain A is updated by the inter-chain messenger to the light client of chain A on chain B. If there is a fake transaction from a hacker trying to cross from chain A to chain B, the transaction will not be verified by the light client as valid unless the hacker attacks the entire blockchain A as a whole. With light-client being the core verification component in this cross-chain design, it would be impossible for a hacker to obtain a valid signature from validators on chain A, hence chain B will not accept such an invalid cross-chain request initiated by the hacker.
MAP Protocol’s cross-chain communication is based on light clients; thus, the whole verification process is fully on-chain, and we do not hold trust assumptions for cross-chain verification.
12. How can an adversary pass a fraudulent message from Ethereum to the destination chain? Please give specific and concrete examples.
No fraudulent message can be passed from the source chain (Ethereum) to the target chain. In MAP Protocol’s security design, when a fraudulent message passes to the MAPO relay chain, the proof it creates cannot pass the verification of light-client on Ethereum.
13. How can an adversary withhold a valid governance message from Ethereum to the destination chain? Please give specific and concrete examples.
As light clients (which are self-verifying) are the ones responsible for verifying cross-chain communication, there will not exist scenarios where a valid governance message from Ethereum is withheld and unable to pass to the destination chain with MAP Protocol’s cross-chain solution. In fact, as long as the massage is valid, anyone should be able to pass the message from Ethereum to the target chain.
14. What are the ramifications of fraud to the malicious actor(s)? If it is legal ramification, please share the suite of legal action you can provide. If it is slashing, please point us to the codebase of the slashing behavior and describe in words how slashing works in your system.
With our fully trustless security design, any fraud action can be checked, and the network will reject fraud messages. Messenger and Maintainer are two cornerstones for cross-chain communication in MAP Protocol. It can be possible that Maintainer or Messenger does not work properly; however, no matter how they can act out, they cannot impact cross-chain verification or allow fraud messages to pass. What they may impact is cross-chain efficiency, but will never affect cross-chain security.
Currently, we do not have a slashing mechanism for Maintainer but we do have an alarm system to prevent Maintainer from acting out. If Maintainer does not submit cross-chain messages to the light client, it will trigger an alarm. Additionally, to be a Maintainer, the party will need to stake $MAPO to work and get rewards, and if they do not work properly, they cannot get rewards or their staked tokens. The slashing mechanism for Messenger, on the other hand, is customizable by individual projects, thus fully depending on how the project wants to work.
Note: Maintainer is an independent inter-chain messenger responsible for updating the latest status of light clients and submitting block headers’ info on each chain as a transaction ultimately to the target chain. Messenger is an independent inter-chain program, working for MAPO Service (an omnichain SDK for dApp developers). It listens to relevant events as preset in the program and builds a proof on the ledger of the source chain; then transmits the message of the event and proof to Vault or Data on the destination chain.
- Provide any additional information you would like here.
As the truly trustless omnichain infrastructure in the blockchain space, we believe that we can contribute to the Uniswap community with our adherence to decentralization and continuous technical innovation.
We know there are many popular cross-chain solutions but they either compromise on the principle of decentralization and the level of security or they are unable to connect all EVM and Non-EVMs. As MAP Protocol will soon connect to Cosmos Hub, it will be another milestone for blockchain interoperability and connect members in Cosmos Hub to members in Uniswap, thus allowing decentralized finance can truly thrive from the bottom up.
