脉波 (MAP Protocol) 是比特币二层和基于轻客户端与ZK的点对点全链基础设施，专注于点跨链互操作，跨链过程中不依赖任何特权第三方，完全点对点，纯代码信任，为 dApp 提供全链智能合约开发平台和比特币生态提供互操作性。

注：此篇白皮书最早发表于2019年并不断更新，与其他社区驱动的开源软件项目一样，脉波白皮书自发布后也持续迭代。该白皮书解释了脉波的基本原理和技术框架，对于系统性研究脉波技术、了解其愿景是必要的。若想了解脉波的最新进展及更新情况，你可以阅读网站内其他相关内容。

---

专注跨链的比特币二层网络

比特币发展历程

2008 年中本聪发表《比特币白皮书》，在短短九页内概述了称为区块链的去中心化分类账的蓝图，并介绍了比特币作为货币的概念。2008年以来，没有实物或内在价值支撑，也没有任何中心化机构控制的比特币不仅生存了下来，而且还蓬勃发展，并成为一些国家的货币储备作为价值储存手段。受比特币影响，加密货币领域也开创了一波波创新浪潮，吸引并激励了 Vitalik Buterin 等人尝试制定更多可编程协议。

而比特币网络机制并非一成不变的，过去十多年来，除去比特币挖矿动态的变化，其网络机制也发生了变化：

• 2012 年，比特币网络通过 BIP 16 引入了 Pay to Script Hash (P2SH)，以简化多重签名交易。 在 P2SH 出现之前，多重签名交易既麻烦又容易产生风险，需要预先披露整个兑换脚本（定义支出条件）。通过 P2SH，用户将资金发送到代表兑换脚本哈希的标准化比特币地址，从而隐藏其复杂性。 只有在花费代币时，完整的脚本才会被公开并满足其条件，这旨在简化交易，增强用户友好性并提高可扩展性。
• 另一项非常重要的比特币改进提案 (BIP)——隔离见证（Segregated Witness），也称为 SegWit，于 2017 年生效。它解决了交易的可扩展性，并有效地将区块大小限制从原来的 1MB 提高到 4MB。
• SegWit 为 2021 年名为 Taproot 的提案打开了大门。 Taproot 使交易更加高效和私密，同时也允许用户参与更复杂的交易类型。

比特币生态的未来

2021 年的 Taproot 升级允许更快地验证多重签名交易，为在最小面额的比特币（称为「聪」）上刻写文本、图像、SVG 和 HTML 打开了大门。2023年5月，随着 BRC-20 这一比特币实验性可替代代币标准的提出和爆火，人们也更加关注比特币生态互操作的未来。

对 BRC-20 资产，脉波提供了一套完整的解决方案，使得用户可以非常方便的将 BRC-20 资产转移到脉波。通过原生比特币上的mapo-brc201协议，用户可以无任何损失的将资产从 BRC-20 协议转移到 BRC-201 协议并跨链到脉波平台。

此外，其他公链上的资产及用户，如何通过点对点跨链互操作，将资产跨到比特币网络，这也是业内一直在探索的技术问题。作为拥有比特币级别的点对点跨链基础设施，脉波也将作为比特币二层致力于实现这一目标，丰富比特币生态的互操作性。

---

点对点跨链智能合约与 Web3 dApp 开发平台

中本聪2019年开发的的比特币对资产和货币而言是革命性的创新。原因就在于，比特币是一种点对点、无第三方信任的电子货币（资产）—— 由一方发起，另外一方接受，不需第三方特权机构。在比特币之前，尽管相关密码学技术的数字签名部分解决了数字货币的问题，但仍然需要一个可信的第三方组织防止双重支付。随着点对点技术取得重大创新，比特币也取得了巨大成功，人们也更加关注区块链行业以及其他区块链技术的应用。

到了2020年，去中心化金融兴起，众多区块链主网相继诞生，用户的跨链需求开始爆发，市场上出现了大批跨链方案。虽然许多跨链方案涌现，但多数方案基本依靠链外第三方角色防止双重支付。也就是说，决定一个跨链事件是否有效，不在于这个事件在起源链是否发生，而在于一组存在信任假设的链外共识节点或角色。尽管它们加入了各种安全假设，但其与中本聪定义的点对点、无第三方角色的去中心化精神是完全违背的。

在众多跨链方案中，虽然 Plokadot 和 Cosmos 解决了点对点跨链互通的问题，但它们仅支持同构链之间的跨链互通，无法满足用户在其他链的跨链需求。整个行业迫切需要一个能够覆盖各种类型区块链、完全点对点的跨链智能合约开发平台。

脉波采用中本聪定义的简单支付验证（SPV) 轻客户端技术，通过将轻客户端验证机制智能合约化，实现了点对点、不依赖第三方、基于代码信任的跨链验证。确定一笔跨链交易是否有效，只依赖起源链是否发生，而非任何形式的第三方链外角色或组织；并通过 ZK 零知识证明技术提升跨链验证效率。同时，MAP中继链创造性地通过内置预编译合约的技术方案兼容了各类Layer1的签名哈希、挖矿算法，实现了异构链之间的跨链互通，以此开启了一个点对点全 dAapp开发的新时代。

---

背景

去中心化金融有以下三个发展阶段：

• 阶段一：比特币点对点电子现金支付系统诞生，开创了加密货币行业，并推动了中心化交易所的发展，也为以太坊和其他Layer1的诞生提供了基础；
• 阶段二：2015年以太坊可编程智能合约出现，推动了公共链Layer1 和去中心化应用的发展；
• 阶段三：全链点对点互操作基础设施 脉波诞生，让dApps无缝覆盖各种链实现智能合约互操作成为可能。

在脉波之前，有以下三种跨链方案：

1. 中心化交易所：其特点是由中心化机构通过KYC、冷钱包、监管合规等方式确保用户资产兑换安全；
2. 链外第三方共识方案：这包括MPC/预言机 (Oracle)/中继链验证人/OP 乐观验证 (Optimistic Rollups)等。MPC跨链桥无法消除特权角色的存在，容易出现坚守自盗或黑客攻击事件；而预言机 (Oracle)方案虽然基于区块头进行验证，但 预言机 (Oracle)节点作为链外第三方，有权篡改提交的区块头信息，从而导致虚假验证；中继链验证人则是对起源链的跨链请求进行跨链验证，即链下验证 (off-chain work)，也属于链外第三方验证，存在共谋风险；OP 验证尽管安全条件设置苛刻，但验证等待时间过长。
3. Polkadot 与 Cosmos：二者属于比特币级别的点对点跨链方案，但是仅限内部生态链跨链通讯，EVM链和其他异构链无法实现与二者的点对点跨链互通。

脉波点对点跨链互操作技术方案

要实现点对点跨链有效性的验证需攻克以下两大难题：

1. 各链的签名算法和Hash算法，区块产生共识机制不同，即异构链之间数据格式不同，各链的数据如何互相通信？
2. 对于链间消息传输程序所传输的跨链请求，如何确保其在起源链真实发生而不依靠第三方？

依靠第三方信任的跨链解决方案

依靠第三方角色的跨链方案通常由一组第三方链外见证人通过某种组织形式，或以质押资产，或以传统世界公信力品牌的方式作为权威角色，来决定跨链请求是否有效，防止双重支付。

一些方案的跨链请求角色和验证角色为同一个角色，另一些方案中则是分开的；一些方案中第三方角色是来自同一条链的验证者，另一些方案中则来自于声誉卓著的品牌组织。第三方共识方案并非依赖代码信任，而是对于第三方角色的信任，这不符合中本聪定义的点对点、无特权第三方角色的去中心化。而Polkadot和Cosmos的方案尽管符合点对点的去中心要求，但无法解决异构链与EVM链的之间的互通问题。

真正点对点、无特权第三方参与跨链，并覆盖各类型区块链

1. 设置一条中继链与任何数据异构的区块链主网实现算法同构

   该区块链有三层，即点对点、共识层、智能合约开发层。不同链拥有不同的签名算法和哈希算法，例如以太坊的签名算法为secp256k1，哈希算法为keccak-256； NEAR的签名算法为ed25519，哈希算法为SHA-256。通俗来讲，区块链的交易是由一方签名后发起这笔交易，另外一方通过破解哈希接受该笔交易，整个过程无第三方角色信任。要构建一个覆盖不同链的点对点交易网络，就需要存在一个中继链同构各种区块链的不同算法。

   MAP Protocol的方案是在MAP 中继链虚拟机开发层，以预编译合约形式内置各种链的签名算法、哈希算法、挖矿及Merkle Tree证明。MAP 中继链需要将主流算法全部同构，当下该中继链预编译合约中已同构的算法如下：

   SHA3

   SHA-256

   ed25519

   secp256k1

   keccak-256

   sr25519

   blake2b

   默克尔证明

   尽管这样的做法工作量非常庞大，但可以让不同算法的目标链读取和验证不同算法的起源链上的跨链交易数据。此处需说明，EVM和非EVM只是虚拟机开发层的不同，而通俗意义上的异构链是指签名算法、哈希算法及挖矿算法的不同。通过中继链达到各链数据同构后，交易数据可以在不同链上被读取。接下来就是要解决在点对点无第三方的条件下，交易无双花的问题。

2. 将起源链上的简单支付验证的ZK 轻客户端以智能合约的形式部署到目标链上。例如点对点跨链交易的发起是从以太坊到 NEAR ，则首先要将以太坊的轻客户端以智能合约的形式部署到 MAP 中继链，然后将MAP中继链的轻客户端，以智能合约形式部署到 NEAR 上。

3. 跨链消息转发。由一组链间程序信使 (Messengers)，负责将起源链上的跨链请求转发到目标链上，再由目标链上部署的起源链 ZK 轻客户端智能合约对跨链请求进行有效性验证。

4. ZK 轻客户端的更新。由一组链间程序维护者 (Maintainers)，负责将起源链共识层最新的区块头和Merkle Tree证明，更新部署到目标链上的起源链轻客户端智能合约中。信使和维护者仅为消息传输角色，无权进行跨链有效性验证，二者若对网络进行攻击，对独立自验证的轻客户端智能合约是无效的。

5. 由部署在目标链上的起源链 ZK 轻客户端智能合约，对链外角色转发的跨链请求进行点对点的有效性验证，并广播网络执行交易。

什么是轻客户端 (Light Client)？

中本聪在比特币白皮书首先定义了简单支付验证（Simplified Payment Verification, SPV) 技术，“不运行一个完整的网络节点也是可以进行支付验证的。用户只需拥有一个最长工作量证明链的区块头副本，他可以通过向其他网络节点查询以确认他拥有了最长的链，并获取链接交易到给交易打时间戳区块的默克尔分支。“

虽然自己不能核实这个交易，但如果交易已经链接到链中的某个位置，就说明一个网络节点已经接受了此交易，而其后追加的区块进一步确认网络已经接受了它。“从这段论述中可以看出，要验证一笔交易在起源链上是否真实发生，只需要看它是否已进入了最长链的区块头中，并且在默克尔树上可以查到它的详细信息。中本聪定义的SPV后来被学术界演进成为轻客户端技术。

为什么轻客户端智能合约可以不依靠第三方、独立自验证起源链上的交易是否真实发生？

尽管预言机 (Oracle)技术方案也是通过区块头进行跨链有效性验证，但预言机 (Oracle)并非智能合约级别的代码信任，而是由一组链外第三方角色组织，他们有权篡改所提交的区块头信息。MAP Protocol的方案是将起源链的轻客户端以智能合约的形式部署到目标链上，在目标链上完全通过起源链的轻客户端智能合约，跨链验证一笔交易是否真实有效。轻客户端智能合约遵循最长链原则，由一组链间消息角色维护者负责同步起源链最新轻客户端状态到目标链上的对应智能合约，该智能合约存储足以满足一笔交易最长链验证的起源链区块头及默克尔树证明数据。

虽然维护者为链外程序，但在轻客户端智能合约正确诚实的初始化状态后（链接的浏览器对应轻客户端页面），维护者并无任何机会篡改随后追加的轻客户端状态，即区块头和默克尔树。这是因为区块链是由包含交易信息的区块从后向前有序链接起来的数据结构，每个区块头都会链接上一个区块头的哈希值，虚假的区块头无法与上一个已存储到智能合约中的真实区块头哈希值匹配；而智能合约是代码信任，任何人无法再去修改它。因此，维护者的任何恶意攻击对轻客户端智能合约都是无效的。另外一方面，对默克尔树的任意部分进行改变的尝试最终都会导致链上某处不一致，从而也让维护者对轻客户端智能合约的攻击无效。

区块头和默克尔树

在一个区块链网络中，区块存储在多层次数据结构中。 一个区块的哈希实际上只是区块头的哈希，区块头是一段固定字节大小的数据，包含时间戳、随机数、上个区块的哈希和默克尔树根的哈希，而默克尔树是一个存储了该区块所有交易的数据结构。 默克尔树是一种二叉树，由一组叶节点、一组中间节点和一个根节点构成。最下面是大量包含基础数据的叶节点，每个中间节点是其两个子节点的哈希，顶部的根节点也是其两个子节点的哈希。

默克尔树的目的是允许区块数据可以零散地传送：节点可以从一个源下载区块头，从其它源下载相关树的一小部分，而依然能够确认所有的数据都是正确的。之所以如此是因为哈希向上传播：如果一个恶意用户尝试替换一个伪造的交易到树的底部，此改动将导致树的上层节点的改动，以及更上层节点的改动，最终导致根节点的改动以及区块哈希的改动，这样协议就会将其记录为一个完全不同的区块（几乎可以肯定是带著无效的工作量证明）。

默克尔树协议可以说是区块链长期持续性的基础。区块链网络中的一个全节点——存储和处理所有区块全部数据的节点，数据规模过大，导致查验一笔交易工作量变大。简化支付确认（SPV）允许另一种节点存在，这样的节点被称为“轻节点”（轻客户端），它下载区块头，使用区块头确认工作量证明，然后只下载与其交易相关的默克尔树分支。 这使得轻节点只要下载整个区块链的一小部分，就可以安全地确定任何一笔交易的状态和帐户的当前余额。

左：仅提供梅克尔树上的少量节点已经足够给出分支的合法证明。

右：对梅克尔树任意部分进行改变的尝试最终都会导致链上某处不一致。

ZK 零知识证明（Zero-Knowledge）

零知识证明是指在不披露声明本身的情况下，验证声明有效性的一种方法。证明者是试图证明声明的一方，而验证者则负责验证声明。通过以太坊社区广泛的知识普及，零知识证明技术的有效性已被业界充分认同。跨链验证中，在不影响点对点跨链有效性验证的基础上，ZK 技术可以让跨链验证时间更短，轻客户端智能合约验证燃气成本更低。

轻客户端与ZK结合的点对点跨链验证方案

在MAP Protocol的技术方案中，ZK 证明负责验证起源链的 BLS 聚合签名哈希值，随后轻客户端智能合约验证默克尔证明，并对ZK 证明进行再次验证。通过结合兼容各类区块链算法的 MAP中继链，脉波达到了符合中本聪定义的点对点无特权第三方的代码信任，且可以覆盖不同类型区块链，真正实现点对点跨链区块链网络。

脉波三层架构

为了兼顾 脉波整体的灵活性和稳健性，MAP Protocol整体技术架构分为三层：协议层、MOS 全链服务层、应用层。

中间层为MOS 全链服务层 (MAP Omnichain Service)，该层是为了帮助 dApp快速部署跨链智能合约应用而提供的一系列组件工具。包括跨链交易转发角色Messenger，以及跨链锁仓智能合约，以及消息跨链组件等。第三层是应用层。该层是MAP Protocol全链智能合约生态应用。

脉波协议层

脉波协议层为最底层，负责跨链交易的验证及点对点执行网络。该层是 脉波的核心，包括MAP 中继链，维护者 (Maintainer) 以及ZK 轻客户端。

MAP 中继链

MAP 中继链是 POS 机制的区块链。与比特币等工作量证明系统 (POW) 相比，对环境更友好。在 POS 机制下，用户可以进行更便宜、更快速且交易结果一旦完成就无法更改的交易。MAP 中继链实现了伊斯坦布尔拜占庭容错 (IBFT) 共识算法，即使多达三分之一的节点处于离线状态，或是错误、恶意的，其中一组明确定义的验证器节点也能按照一系列步骤在它们之间广播签名消息以达成协议。 当法定人数的验证者达成一致时，该决定就是最终决定。MAP中继链的独一无二的特征是其在预编译合约中，内置了几乎所有链的不同核心算法。

维护者 (Maintainer)

维护者是一组链外角色 ，负责将起源链共识层最新的区块头和默克尔树证明，更新部署到目标链上的起源链轻客户端智能合约中。虽然维护者为链外程序，但在轻客户端智能合约正确诚实的初始化状态后（链接的浏览器对应轻客户端页面），维护者并无任何机会篡改随后追加的轻客户端状态，即区块头和默克尔树。因此，维护者的任何恶意攻击对轻客户端智能合约都是无效的。

ZK轻客户端运行机制详解

用轻客户端完成跨链验证是点对点的去中心化，但验证成本相比于其他依赖第三方觉得的跨链方案则会更高，效率也会相对偏低。因此，脉波创新性地引入 ZK 技术，用ZK优化轻客户端点对点跨链验证，优化验证费率。

轻客户端跨链点对点验证机制

PoS机制的 L1 与POW机制的 L1 存在不同的区块头类别。PoS机制下，区块头校验的核心是校验Validator的签名信息。具体的实现逻辑如下：

起源链为PoS机制区块链

当起源链轻客户端部署在目标链上智能合约后，在起源链的验证者集合换届的情况下，维护者会将起源链验证者集合的 BLS 聚合签名和投票权重写入目标链上部署的起源链轻客户端智能合约，目标链上部署的轻客户端智能合约存储起源链多届（中本聪最长链原则）验证者委员会的验证者公钥和投票权重；因 POS 机制链的每届验证组都由上一届验证组委员会签名授权产生，维护者作为链外程序，若试图写入虚假的起源链验证者集合信息到目标链轻节点，存储在轻节点（轻客户端）智能合约中上一届验证组的签名验证者信息校验并不会通过其写入请求，因为虚假的签名验证者集合并无上一届委员会的签名授权；若要通过，则需要攻击整个起源链，或者重写智能合约。至此，点对点的独立自验证得以保证。

起源链为PoW 机制区块链

其起源链轻客户端部署在目标链上智能合约的情况下，维护者负责同步起源链最新区块头信息至目标链轻客户端合约；目标链上部署的轻客户端合约存储起源链最新的第N个区块头；维护者若试图将虚假区块头写入起源链，虚假信息并无匹配的上一个区块头哈希值，故并不会被存储在目标链上的轻客户端智能合约接纳。

MAP 中继链用 ZK 技术优化后的轻客户端验证

脉波的跨链验证主要由部署在目标链上的起源链轻客户端智能合约执行以下两种验证：

1. 区块头的正确性验证：验证维护者请求写入的区块头的合法性，根据链共识机制的不同，该验证方案会有所差异。对于采用PoS和BFT机制的链，通常是验证区块头中包含的合法签名所代表的投票权重超过2/3。
2. 默克尔证明的验证：验证在特定的区块高度中有emit特定事件，所需的正确的Merkle根值在区块头中，由第一步确保正确性，在与以太坊结构类似的区块链群体中，该默克尔证明通常是Merkle Patricia Trie的存在性证明，也即收据树MPT中确实存在特定的event。

基于zkSNARK 技术来改进MAP中继链的轻客户端实现，旨在解决两个问题。

1. 减少轻客户端合约中所需存储关于MAP中继链元信息的数量，降低轻客户端本身状态更新时的燃气费消耗；
2. 将区块头合法性验证过程中签名合法性以及签名权重检查部分放入零知识证明电路中，利用Groth16方案完成验证，以降低燃气费消耗。

在MAP中继链轻客户端智能合约中，需要存储当前epoch的所有验证者的公钥以及质押权重信息。当验证新区块头的合法性时，根据区块头中的信息和轻客户端自身存储的当前验证者信息，轻客户端合约可以计算出验证区块头中聚合签名所需的聚合公钥。如果聚合签名验证通过，并且聚合公钥所代表的验证者的投票权重之和超过了2/3，那么区块头就会通过验证。基于zkSNARK构建的MAP中继链轻客户端中，只需要存储关于当前验证者集合元信息的commit值，即SHA256((pk_0, wt_0), (pk_1, wt_1), ... , (pk_n, wt_n))。这意味著轻客户端合约从需要存储n个公钥和权重信息精简为只需要存储256比特的commit值。

因此，基于zkSNARK构建的MAP中继链轻客户端的区块头验证逻辑可以简单表述为：输入的区块头在当前commit值所代表的验证者集合信息中是否为正确的区块。这一判断的成立与否取决于随著区块头一起输入的zkSNARK证明。

引入zkSNARK后的更新

为了表述清晰，以下是引入zkSNARK后跨链流程中新引入的证明人 (Prover) 的角色以及更新的messenger/maintainer的逻辑，以及每一方所接受的输入：

1. Prover的输入为：区块头、当前验证者集合中每个验证者的公钥以及投票权重。
2. Circuit的输入为：t0 和t1、待验证的聚合签名、当前验证者集合中每个验证者的公钥以及投票权重、指示聚合验证者的bitmap.
3. 轻客户端验证event合法性的输入为：区块头、zk-proof以及mpt-proof。
4. 轻客户端验证sync commit合法性的输入为：区块头、zk-proof。

其中，t0和t1是区块头hashToG1的中间值，参考当前的轻客户端实现代码。之所以circuit选择t0 和t1作为输入，而非区块头整体作为输入的原因是：hashToG1的计算内部hashToBase用circuit来表达代价比较大，得不偿失。当prover服务器拿到maintainer或者messenger提交的区块头信息之后，继续执行相关操作。

Prover可以理解为生成证明的伺服器，对外暴露一个证明生成请求接口，接口的输入参数为：区块头、当前验证者集合每一个验证者的公钥以及投票权重。接口的输出为zk-proof。由于前述原因，prover在开始计算zk-proof之前，首先从请求中的区块头中抽取并计算出生成zk-proof所需的参数： t0 和和 t1 、指示参与聚合签名的验证者的bitmap，然后执行zk-proof的具体计算过程。

Circuit 内部编码的逻辑

1. 根据区块头中bitmap的指示以及全量的验证者集合的信息，计算出聚合公钥，校验聚合公钥所代表的签名权重超过了2/3。
2. 根据 t0 和 t1，计算出 hashToG1 的最终结果，利用该值、待验证聚合公钥以及聚合BLS验证，检查签名合法性。

而最终的zk-proof也就是为上述statement在特定public input下的合法性做了断言。在轻客户端验证区块头的过程中，会根据自己存储的commit信息以及待验证的区块头信息，构造出public input，并验证zk-proof的合法性。如果能够验证通过，则意味著该zk-proof有效，进而证明了相应区块头的合法性。

示例说明

以轻客户端验证事件合法性为例，其输入包括区块头、zk-proof以及merkle-proof。整个证明验证过程如下：

1. 根据输入的区块头，以及hashToBase计算出t0和t1。
2. 将t0和t1以及自身存储的当前验证者集合的commit作为公共输入，按照groth-16方案验证zk-proof的合法性。
3. 如果第二步验证通过，则表示区块头是合法的，接著从中提取出Merkle Patricia Tree（MPT）的根节点（MPT root），继续验证mpt-proof的合法性。

步骤一是为了配合circuit的构造方式，引入的额外计算也是用合适的方案验证做合适的事情的原则体现：hashToBase所涉及到的计算用solidity完成代价不高，用circuit来做则得不偿失。区块头验证的关键步骤是第二步，第二步实际上是验证了一件事情：输入的区块头在轻客户端存储的commit所对应的验证者集合下是一个合法的区块头。这一推断根据circuit的内部逻辑容易推断出来。第三步则与目前轻客户端的实现没有差异。

轻客户端验证同步提交合法性的过程与上述过程基本保持一致，唯一不同的是将第三步的验证MPT根合法性的操作替换为根据新的验证者集合信息重新计算commit，并更新自身存储。

总结

根据前述论述，MAP中继链的轻客户端在基于zkSNARK升级之后，maintainer/messenger需要做的相应调整如下：

1. Maintainer想要更新轻客户端状态前，需要从prover处获得zk-proof，并用区块头、zk-proof构造tx。
2. messenger想要调用发起跨链请求前，也需要从prover处获得zk-proof，并用区块头、zk-proof以及mpt-proof构造tx。

透过前端进行跨链交互的用户，通常会感受到背后发生的变化。为了突出零知识证明的特性，可以在前端展示一些与零知识证明相关的信息：

1. 当messenger提交zk-proof请求后，前端可以简单地显示通知提示，例如：“已提交跨链zk-proof请求给证明者”。
2. 当messenger获得zk-proof请求后，前端可以简单地显示通知提示，例如：“已获得zk-proof”。
3. 当messenger提交包含区块头、zk-proof以及mpt-proof的交易后，前端提示：“已提交zk-proof和跨链请求给目标链”。

在第三步的交易打包后，前端可以提示：“zk-proof和跨链请求已被目标链处理”。

通过比特币网络进一步确保 MAP Protocol 网络的安全性

在区块链中，长程攻击是一种特别针对证明权益（Proof of Stake，PoS）系统的攻击方式。攻击者尝试创建一个从区块链早期历史开始的分叉链，如果成功，这可能会重新定义链的权威历史记录，导致双花问题（Double-Spending）或破坏网络信任。中继链架构中，这个问题尤其重要，因为它们常常负责协调一个网络中多个独立区块链的交互。如果中继链遭受长程攻击，这可能影响到所有依赖其作为信任和通信基础的链。

比特币以其巨大的算力保护，可以被看作是一个天然信任源，其引入了一种由工作量证明提供支持的时间戳服务器。它为事件提供了不可逆的时间顺序。在其原生应用中，事件是在比特币账本上执行各种交易。在目前增强其他区块链安全性的应用中，比特币也可用于对其他区块链中发生的事件添加时间戳。每个此类事件都会触发发送给矿工的交易，矿工随后将其插入比特币账本，从而为事件添加时间戳。为事件加时间戳的交易称为检查点（checkpoints）。

检查点可以通过使用比特币的 OP_RETURN 操作码来实现，该操作码允许在不可花费的比特币交易中发布 80 字节的任意数据。每个检查点必须至少包含要检查的 PoS 区块的哈希（32 个字节）以及最终确定该区块的签名（每个 32 字节）。在这里，哈希用于识别被检查点的 PoS 区块。哈希用于识别被检查点的 PoS 区块。需要签名来防止对手发送任意哈希并假装其正在比特币上检查 POS区块。

POS链可以通过比特币时间戳服务的特性，来增强其安全性，解决POS链长程攻击问题。脉波定期（每个epoch）将每个epoch的最后一个区块的哈希及签名提交检查点的方式提交到比特币网络，检查点由区块的哈希以及单个聚合 BLS 签名‌组成，该签名对应于已签署区块以进行最终确定的 2/3 验证者集的签名以及 epoch 编号和bitmap编号。为此 MAP Protocol 客户端可以通过检索比特币网络上的检查点来判断 MAP Protocol 平台POS链的最终规范链，从而防范恶意验证者对脉波实施的长程攻击。

MAP 全链层 (MOS)

上面章节提到，MOS包括Messenger 信使和Vault合约，以及消息跨链等组件。

信使 Messenger

信使是一个独立的链间程序，监听程序中预设的相关跨链事件，当跨链事件发出后，在起始链的区块中构建一个该事件已上链的证明。然后将该事件的消息和证明传送给目标链上的 Vault合约。

Messenger 需要为终端用户预付MAP Protocol 网络或目标链的gas费。由于目标链的gas费无法估计，Messenger的奖励或回报需要从 dApp 方获得。应用程序的灵活性为 Messenger 提供了许多可能性，应用程序可以向全链用户收取灵活的交易费用并相应地奖励 Messenger。作为 MOS 的主要组成部分，Messenger 的SDK对dApp开发者完全开放。

Messenger是一个高并发的链间程序。理论上，只要有一个诚实的Messenger在链间工作，所有dApp的跨链交易信息都可以被传输；Messenger 的恶意攻击不会导致资产损失，只会导致 脉波协议层的跨链验证不会通过。

Vault & 数据合约

在起始链上Vault 和数据合约负责接收资产或数据，并发送事件给Messenger，

在中继链或目标链上，Vault 和数据负责接收 Messenger 传送的跨链信息，并将该请求转发到部署在中继链/目标链上的起源链轻客户端验证。验证完成后，Vault 和数据则会执行相应的指令。

MAP Protocol 应用层

应用层开发中，智能合约消息跨链及资产跨链是如何执行的，这对开发者非常重要，以下进行说明。

资产跨链

资产跨链环节中，当一笔交易发起点对点跨链请求后运转详情如下：

1. Vault跨链智能合约（MOS组件）收到资产。
2. Vault合约发射包含有起源链地址，目标链地址，代币种类，金额的信息给到Messenger。
3. Messenger监听到这一事件，同时，为了验证这一事件的真实性，Messenger 需要在起源链上构建一个该事件上链的证明。
4. Messenger转发这个请求到中继链vault合约。
5. Vault合约将这一请求的真实性，交给起源链部署在中继链上的轻客户端智能合约进行验证。轻客户端智能合约存储了起源链最长链区块头信息，可验证该笔交易是否在起源链真实发生。
6. Vault合约在中继链上铸造同等数量的中继链版本的跨链请求资产。
7. Vault合约销毁铸造的资产。第六步和第七步是为了在中继链记账，所以铸造后又销毁。
8. Messenger监听到中继链上的事件，并在中继链上构建一个该交易上链的证明；
9. Messenger将消息转发到目标链的Vault合约；
10. Vault合约将跨链请求交给中继链部署在目标链上的轻客户端智能合约进行验证；
11. Vault合约收到轻客户端验证通过指令，将代币释放给起源链智能合约指定的目标链地址。

数据跨链

消息跨链适用于智能合约互操作，其基本步骤与资产跨链相同。

消息跨链有众多应用场景，智能合约跨链互操作是最值得关注的场景之一。去中心化金融的核心是可组合，同链间的智能合约组合带来了巨大的 DeFi 应用市场。不同链间智能合约的组合可以带来显著的去中心化金融效率提升。一个用户或一个智能合约，无论使用在任何链上任何代币，都可以去操作其他链上的 DeFi 产品，并在执行结束后，点对点 (Peer-To-Peer) 返回其原有的链上的原有资产。

MAP Protocol 代币经济

作为面向全链dApps 全链网络基础设施，MAP Protocol 致力于打造一个任何角色都可以参与的开放经济体，创建可持续的激励结构，并为生态系统运营、发展计划和战略投资提供动力。许多公共区块链项目的货币系统仅用于激励节点运营商。MAP Protocol 代币经济旨在激励来自更广泛参与者的更多样化形式的贡献，并具有内置的激励结构，除了维护其区块链节点外，还能获得持续的资源，为未来的发展计划和战略投资项目提供动力。

分配与释放

代币 MAPO 总供应量为 100亿，其分配释放符合网络区块的生成与网络维护、生态系统发展和社区成长的激励。具体比例分配及比例如下：

• 15% 为团队激励，2019 - 2025 年为代币锁定期。
• 21% 属于 Ecosystem DAO，没有锁仓且完全由社区决定代币使用策略。在 MAPDAO 的治理体系中，所有会影响到社区成员的决议都要先在 MAP Protocol 论坛上充分讨论并形成最终方案，最后移至链上由 MAPDAO 投票决定。
• 12% 为 MAP Protocol 基金会所有，用于 MAP Protocol 生态建设与 Web3 全链生态的拓展。
• 22% 为投资者和早期支持者所有。
• 30% 为挖矿奖励，发给保护 MAP Protocol 网络安全的验证者和链间更新轻节点状态的 Maintainer。

收费模型

MAP Protocol 只收取跨链交易中MAP Protocol 网络上产生的燃气费用;Maintainer 可以从 MAP Protocol 中获得额外的奖励，用于更新和维护轻节点。

链链间信息传递程序 Messenger 是MOS的重要组成部分。Messenger 需要预付MAP Protocol 网络和全链用户的 燃气费用，这部分费用无法被估计。因此，MAP Protocol 为开发者提供全套 Messenger SDK。应用层为 dApp开发者提供灵活性，以确定跨链交易费用标准、对Messenger 的奖励以及具体要求。

部署在每个链上的Vault & Data也是MAP 全链服务(MOS)的重要组成部分，负责管理每个链上的资产 (可置换代币和NFT)和消息数据。对于 Vault 和数据的开发者，MOS 不收取任何费用。应用程序可以自 行决定分享 Vault &和数据的流动性的收费结构。

未来 15 年预估解锁时间

未锁仓代币(即能够用于分发的代币)和锁仓代币(不可用于分发的代币)都可以参与质押; 未来15年流通代币供应总量会受主网表现和质押预测的影响。

社区成员如何参与

MAP Protocol三层结构中，每一层都有社区成员参与的机会。

在脉波协议层

• 成为验证者: 验证者是 MAP Protocol 网络的基础。社区成员可以质押 $MAPO，建立一个具有所需计算能力的节点，以运行一个验证节点，从而获得代币激励和gas费分配。社区成员也可以将他们的$MAPO委托给其他验证节点操作者。
• 成为维护者 Maintainer：Maintainer 的价值在于更新部署在目标链上的轻节点状态，以便验证网络能够顺利运行。当Maintainer 更新轻节点时，必须在链上写入一笔交易，从而导致该角色需要支付目标链上的燃气费。因此，脉波经济模型单独设计了一部分来激励和补偿 Maintainer。 Maintainer 的运行需要有计算能力，有足够的资金流提前支付目标链的燃气费用，并质押 $MAPO。

在 MOS 全链服务层

• 成为流动性提供者：社区成员可以通过部署在脉波生态系统中的dApps向每个链上的Vaults提供流动性。每个dApp直接设计激励模式。
• 成为信使 Messenger：Messenger 运行需要为MAP Protocol 网络（$MAPO）和目标链（本地代币）提供足够的燃气费用。每个dApp 制定可激励模式。

在脉波应用层

• 作为dApp开发者: 通过 脉波全套SDK，dApp 开发者可以开发各类全链应用。

脉波应用场景示例

全链代币发行

一个项目发行代币时，往往要多链割裂发行，让用户再通过外部桥操作复杂的跨链兑换；然而，通过MAP Protocol，项目方可在代币发行时就实现全链覆盖，并且各链互相自动账本对齐，通过消息跨链实现内在的跨链兑换互通，尽管用户无感多链的存在，但的确存在多链，如同境外美元和境内美元的使用一样。

全链借贷

如果一位用户在A链上有资金，但想在B链上挖矿，那么这位用户必须经过以下9个步骤，每增加的一步都意味着增加的摩擦成本。

在A链上质押到借款 到 跨链桥 到 交换 到 在目的链上挖矿 到 交换回来 到 跨链回来 到 偿还贷款 到 取消质押。

通过 MAP Protocol，用户可以直接在A链上质押，在目标链上完成借款、挖矿、还款、解锁质押，直接跳过四次跨链桥和交换。

全链 Swap

通过连接最好的跨链DeFi协议，用户使用全链 Swap时，只需花费远低于传统DeFi交易所的费用换币。通过 MAP Protocol，开发者可以建立一个点对点 (Peer-To-Peer) 的全链交易所，让用户可以交换任何链上的任何代币。

全链 Swap 还可以通过连接主流 DEXs 的流动性实现全链的聚合交换。现有的AMMs可以被打包，实现从一种资产到另一种资产的全链交换，不需要修改任何现有代码。用户想从以太坊的 $ETH 交换到 NEAR 链的 $NEAR，只需在源链上进行一次交易。

在用脉波构建的全链交换中，用户可以在一个池子里增加多链币种的流动性，这意味着向来自不同链的代币对提供流动性将成为可能。用户可以直接将一个代币换成另一个不同链的代币，而不使用任何中间代币如稳定币，从而实现全链互换的最短路径。

全链 GameFi

随着加密货币行业和元宇宙理念大热，很多创新理念被带到了传统游戏领域。GameFi 指的是金融系统的游戏化，通过参与玩赚的加密货币游戏来创造利润。玩赚游戏与传统游戏不同，因为玩家参与游戏是为了赚取奖励，玩家可以创造游戏中的资产，并对所有权进行完全控制。

全链 GameFi 指的是将游戏内所有的行为交互及目标状态全部上链，即核心的游戏逻辑以及经济模型都经由区块链处理，将区块链作为游戏的服务器，而玩家所有的操作均通过与智能合约的交互完成，甚至连游戏的叙事和治理也通过 DAO 的形式完成去中心化。

脉波可支持不同类型区块链的跨链互操作，GameFi项目可以通过在 MAP Protocol 网络的互操作性，不仅与EVM和非EVM链有效、安全地连接起来，还能实现其存储、计算都在链上。此外，MAP Relay Chain将主动链接不同类型的链，以便 GameFi 项目可以专注于提升用户体验，而不必担心扩展性和安全问题。

链上数据：链上预言机和衍生品

去中心化的衍生品和合成资产通常受制于源自其他链的资产价格和数量的准确性和及时性。这个问题可以通过多链部署来解决，但这非常复杂。

通过建立可靠的全链网络，脉波实现了数据跨链，并正在培育一个全新的预言机市场——链上预言机。通过在MAP Protocol 网络上的部署，衍生品和合成资产应用可以很容易地从链上预言机获取可靠的多链数据。

全链治理 （以 AAVE为例）

AAVE 执行一项提案时（这项提案建立在以太坊网络上），该提案会被发送到 Polygon（MATIC）FxPortal。然后，该机制读取以太坊上的数据，然后传递给Polygon网络进行验证。之后，AAVE 跨链治理的桥接合约收到了这些数据，对其进行解析并排队等待下一步，等待时间锁定来完成。

AAVE 跨链治理桥是常见的跨链方案，可以与任何支持EVM的链完成跨链信息传递的操作。目前，该 Repo 支持与Polygon和Arbitrum的合同桥接。在 AAVE 上，用户可以提交 AAVE 改进协议或AIP，以针对性提升DeFi平台的各种功能。

虽然目前看来该方案已比较完备，但若通过 脉波的全链互操作性，AAVE 链上治理可以实现对所有EVM和异构链的全链管理。

可置换代币和 NFT 桥

代币跨链桥和NFT 跨链桥不再需要建立自己的基础设施或使用第三方信任机制跨链，而通过脉波点对点、无特权第三方角色的底层跨链验证网络和MOS应用开发者服务包，跨链桥开发者可以轻松建立他们的 NFT 或同质化代币桥接器应用。

AIGC + Web3

AIGC产生的用户AI数据资产可存储在去中心化存储L1上。但数据资产要实现交易就需要去中心化，并以 DeFi 市场活动繁荣的 L1 作为支撑；通过点对点跨链消息传递，AIGC 数据资产的交易将成为可能。

BRC-20 资产流通

BRC-20 是一个实验性质的比特币网络同质化代币标准，是在比特币网络上的铭刻资产。通过原生比特币上的 mapo-brc201 协议，脉波支持将比特币网络上的铭刻资产，即 BRC-20 ，以点对点的方式跨链转移到脉波平台，让其他公链上的币与 BRC-20 资产以更方便、更低成本的路径实现交易，同时实现铭刻资产的价值流动性。

这一互操作性有助于扩大比特币网络的用例，将比特币生态整合到更广泛的加密金融生态系统中，从而也比特币社区带来新的贡献。

结论

脉波协议即 MAP Protocol ，是比特币二层网络，也是一个点对点的全链互操作网络，专注于跨链互操作性。它为基于区块链的资产、存储和计算提供了实现跨EVM和非EVM链互操作性的基础设施。作为一个全链基础设施，脉波上不依靠信赖任何第三方进行跨链通信。唯一信任的是代码，这些代码利用轻客户端的自验证特性，以完全点对点的方式进行跨链。当源链上发生跨链请求时，它将通过链下角色传输到目标链。然后，部署在源链上的轻客户端将以点对点的方式验证链下角色发送的跨链请求的有效性。

此外，脉波的安全性通过比特币网络进一步加强。所有相关信息，如 epoch 和 MAP Protocol 网络 的PoS共识，都作为交易写入比特币区块。这将防止对中继链的长程攻击，利用比特币网络安全机制进一步确保中继链的安全。

脉波协议是灵活、创新的全链互操作基础设施，也是点对点跨链互操作与 Web3 dApp 开发的平台，而非专门针对某一特殊用例封闭式、单用途协议。脉波协议在设计和社区上都是开放式的，我们期待脉波作为更多新金融和非金融协议的基础。