提到 Celer，许多人首先想到的就是其明星跨链桥产品 cBridge，在多链生态的发展趋势逐渐明显后，跨链成了许多团队创业的方向。虽然整个跨链赛道安全问题频发，但 cBridge 自 2021 年上线至今却未曾出现过任何安全漏洞。在跨链领域龙头地位稳固的当下，Celer 于 3 月也发布了自己的最新 ZK 研发成果 – Brevis。
专注 ZK 技术的 Brevis 来的恰逢其时，在 Arbitrum 空投大热后，许多 ZK 生态的明星项目也已蓄势待发。今年，zkSync、StarkNet 等诸多 ZK 龙头也都先后宣布了主网上线的消息。在「ZK 元年」发布自己的「ZK 新品」，是否是 Celer 转移发展方向的信号？团队选择 ZK 技术的原因是什么？Brevis 又承载着什么使命？
Bitbili 针对这些问题，在 Celer 联创董沫博士参与香港 Web3 Festival 期间对其进行了深度采访。
董沫博士在 Web3 Festival 上发表演讲，图源来自 Celer
新领域的英勇探索者
从状态通道领域的状态守卫者网络（SGN）到跨链桥领域的 cBridge，再到最近发布的 Brevis，Celer 总是能给新生态或新领域带来创新且可靠的产品。但在外界看来，这似乎也是 Celer 团队频繁切换赛道的表现。Celer 团队究竟是什么样的？在行业中到底是怎样的定位？
Bitbili：一些读者可能对 Celer 以及董沫博士不是很熟悉，请您先简单做一个自我介绍吧。
董沫：我之前在 UIUC 读 PHD 期间跟导师一起做了一个公司，主要方向是网络安全，后来这个公司被 VMware 收购。我自己 PHD 的研究课题一直是分布式系统、网络系统等相关领域，这也是为什么我很早期就看到了区块链技术。
PHD 毕业后，我经常在湾区参加各类讲座，也常和好友们聊起区块链，其中就包括现在 Celer 的几位创始成员。我们都认为区块链是一个非常好的机会，而且也都非常感兴趣，因为我们都研究分布式系统，是一个门派出来的。后来大家决定开始做 Celer，一开始主要是做二层扩容。扩容当时有很多的技术方向，一个是通过建立更快的公链或者侧链的方式，另一个就是二层解决方案。
当时，二层解决方案是在比特币闪电网络的基础上去构建一个新的东西。因为比特币闪电网络只能做支付，而以太坊则有状态通道网络，这也是 Celer 一开始在做的东西，通过状态通道网络去提升以太坊性能。我们做的状态通道，也是世界上第一个广义状态通道网络。这是 Celer 一开始的初衷：希望通过提升以太坊性能让更多的人能触并使用区块链。
Bitbili：Celer 后来为什么放弃了状态通道方向的开发呢？
董沫：原因之一是在于它的开发门槛比较高，需要改写现有的智能合约。状态通道这条路，我们其实可以说是「英勇地进行了探索」，目前还没有到成熟的时候。那什么时候状态通道才会「Great Again」呢？就是在区块链上真正出现很多传统支付场景的时候。因为传统支付中不可能让每一笔支付都产生 Gas，甚至二层解决方案也不够便宜，但状态通道网络能给你带来的支付体验是最极致、最低成本的。就目前的行业状态来说，我们认为做状态通道还是太早了，但我们对状态通道的未来应用仍然充满信心的。
在我们状态通道的架构中有一个技术栈叫做「状态守卫者网络 – SGN」，它的职责是把链下的数据安全地中继到链上去，并且在链和链之间中继信息。在 2021 年我们看到行业多链发展趋势出现后，立马就意识到我们之前的研究在这个领域显然是能够用得上的，所以我们就果断地选择了跨链这一新的发展方向。
为智能合约开「天眼」
「Celer 转向 ZK 了」，当问起身边的朋友时，大家都知道 Celer 最新的发展方向。但对 Celer 为什么采用 ZK，以及 Brevis 究竟是做什么这些问题，却并不是非常了解。但实际上，在复杂技术理念和拗口组件名称的背后隐藏的，是一块巨大的行业空白和商业机会。
Bitbili：Celer 团队为什么要推出 Brevis？它解决的是什么问题？
董沫：如今，无论市占率，还是合作伙伴，Celer 在跨链领域已经做得非常好了。今天，用户打开 MetaMask 钱包后会发现多了一个「Bridge」功能，而 Celer 就是除 Connext 和 Hop 之外的另一个主要跨链合作伙伴，直接接入 MetaMask 的流量，这也间接证明了在 Celer 在跨链领域里取得的成功。此外，除了 Celer 支持的 40 余条公链外，日本的著名公链 Astar，SEGA, SquareEnix 等日本最大游戏公司支持的 Oasys，韩国游戏公司 Netmarble 旗下的 Metaverse World 侧链等等都选用 Celer cBridge 作为官方跨链桥，同时 Celer 的生态开发者使用 Celer 在元宇宙，NFT，DeFi，Governance 等等各个领域也开发了近百种跨链应用。
在深耕跨链领域的过程中，我们也跟许多多链应用团队进行了非常深入的交流。我们发现，单纯的消息/资产跨链并不能满足他们的需求。就目前而言，消息/资产跨链仍然是一个主动的过程，相当于一个应用在链上即刻产生了一个新的消息，需要将他发到其他链上。但如果一些应用想要读取和使用链上任意时间的任意信息时，就行不通了。（Bitbili 注，更多关于跨链原理的内容请阅读《当你在进行跨链时，资产真的转移了么？》）
举个例子，DeFi 应用在跨链分配其 DEX 流动性池时，是需要分析各链的相关历史数据去决定分配激励的。但目前大家只能通过定期治理的方式，将链下「人眼」看到的数据放回到链上。但自始至终中，智能合约都是一个「瞎子」，它没有办法看到自己链上过去的数据、也看不到别的链上或者合约里的私有数据，所以也不能对这些数据进行计算、验证和利用。于是我们投入了大量时间精力，研发了一个基于 ZK 的全链数据验证计算平台，Brevis，为这些智能合约开「天眼」。
这是 Brevis 要解决的问题：让链上的智能合约无需信任任何第三方地去获取、计算、和使用所有链上面的所有数据。
Bitbili：关于链上数据索引和分析，Dune 或者 Nansen 已经有了相对成熟的产品，Brevis 和它们相比有什么不同呢？
董沫：这是很多人都有的疑问。实际上，Dune 和 Nansen 做的数据都是给人看，而不是给智能合约看的。Dune 和 Nansen 从 RPC 里面把数据挖出来，总结到一张图表上让人去读。这个给人看的数据，需要你完全信任这个 RPC，也就是要去相信一个中心化第三方。
但是要做让智能合约看的数据，就需要把 Dune 或 Nansen 图表上的数据「塞回」智能合约里。这里存在一个很简单的问题：「塞回」数据的真伪，谁有权力说了算？目前链下依然没有一个去信任的方法来证明数据的真伪，这是一块很大的「Missing Piece」。让智能合约能拥有自己的「Nansen」，让现有应用能够真正成为链上数据驱动的 Co-Processor 应用，这是 Brevis 最不一样的地方。
Bitbili：您能否简要介绍 Brevis 中 zkFabric、zkQueryNet 以及 zkAggregator Rollup 三个主要组件的作用？
董沫：zkFabric 主要帮助整个 Brevis 从所有链接的区块链中收集 Block Header，以及其在各个链的聚合和分享器。通过 ZK 轻客户端电路证明其有效性后，生成共识证明。这个组件对于 dApps 以去信任的方式访问 Block Header 以及区块链的状态至关重要。我们可以这样理解 Fabric 的作用，比如说在 Brevis 上接了 10 个链，这 10 个链之间能够互通有无，不光是消息型数据，而是所有的历史数据。但我们仍然需要一个东西证明这 10 条链的 Block Header 是正确的，zkFabric 就有这样一个证明者网络去证明、中继和存储所有 Brevis 支持的链，为这些链提供一个完整的历史总结。
zkQueryNet 是一个提供 ZK 查询引擎的开放市场，它基于 zkFabric 的总结，能够做任意数据的展开，可以直接接受智能合约的数据查询要求，并通过 ZK 查询引擎电路生成查询结果和 ZK 查询证明。相当于 Dune 上面的一个 Index。你可以把链上的智能合约想成用 Dune 的一个用户，他可以直接用 Dune，不需要有任何人告诉他 Dune 的结果是什么，直接建立自己的 Query。Query 的形式可以是一个 API，或者一个非常通用的 Query 语言，用户写一个 SQL 或者一个 Graph 就可以查到后续的状态，这个东西就是 Brevis 的 zkQueryNet 现在正在做的。
zkAggregator Rollup 是一个聚合层，相当于把 zkFabric 里面已经证明过的 Block Header 和 zkQueryNet 里面证明过 Query 聚合在一起。zkAggregator Rollup 是一个非常特殊的 Rollup，它验证来自上面两个组件的证明，并将它们的 ZK 证明状态根提交给所有连接的区块链，来让应用直接在自己的智能合约中访问证明查询结果。举个例子，现在有三个人在互相传递信息，为了同步消息，每个人都要把自己的 Block Header 中继给另外两人，最后要发 6 条消息。zkAggregator Rollup 的作用就是，三个人各自发一条消息给它，它再各发一条消息给我们，相当于一个中继器。
Brevis 技术结构图，图源来自 Celer
而 zkFabric、zkQueryNet 以及 zkAggregator Rollup 都需要有 ZKP 组件。zkFabric 用于证明 Block Header 是否正确，zkQueryNet 用于证明数据分析结果是否正确。而如果把 zkAggregator Rollup 简单理解成一个 Recursion 的话，它的逻辑就是去「证明所有的证明」，这个证明的过程本身也在被 zkProve，可以一层一层去叠加。（Bitbili 注，更多关于 Brevis 技术原理的内容请阅读《解读 Celer 的 ZK 全链数据计算和验证平台 Brevis》）
能让 DEX 快速超越 CEX 的「Missing Piece」
了解 Brevis 的具体架构后，接下来的问题，就是它能干什么？
Bitbili：您刚才提到 Brevis 在 DEX 领域的用例，能否进一步解释为什么 DEX 需要将历史数据「ZK 化」？
董沫：其实现在的 DEX 不算完全的去中心化，很多环节还是依靠人工管理，要花费很多的时间。比如一个链上的应用想基于链上交易数据对自己的流动性池和激励阈值做调整，目前来说是没有办法摆脱人为 Governance 治理的。
再比如，DEX 与 CEX 的一个重要区别就是 DEX 没有 VIP 分级系统。如果一个 VIP 用户希望能够降低自己的交易费，DEX 必须通过 Governance 治理来完成，而且就算通过 Governance 能够降低费用，在时效性层面也非常不理想。更何况，作为交易员，每个人达到比如 100 万美元交易额的时间点都是不一样的，DEX 想要做到「交易额达到 100 万美元就可以享受 7 天减免交易费」这种效果，没有基于全链历史数据的 zkQuery 是无法实现的。
但是市场有没有这样的需求？答案是不仅有，而且很大。因此我们需要有这样一个技术，帮助智能合约任意获取全链过去、现在、未来的数据，然后再基于这些数据去做计算。
专业做市商、交易折扣还有用户 VIP 分级系统等这些中心化平台常用的机制，是能够 DEX 生态更加健康的重要因素，过去 DEX 没法做这些东西，现在我们可以帮它们实现。比如一个用户在 Polygon、BNB 和以太坊上都用过 Uniswap，Brevis 可以帮助 Uniswap 以一个完全去中心化的方式去计算该用户在各条链上任意时间段的交易量总和。
Bitbili：您觉得除了这种数据驱动的 DeFi 之外，Brevis 在中短期还有什么较强的应用场景？
董沫：还有一个很大的应用场景，就是链上的身份证明（DID）。比如说，虽然我没有在 BNB 链上做过交互，但我要证明自己是一个以太坊老用户，甚至 17 年还参与过 The DAO 的治理，然后通过这个证明让我在 BNB 链的应用里能够获取新的权益或者空投。换句话说，就是我可以给自己打很多的链上标签，能够让应用看到过去这些数据，证明我的身份，其实这一块最大的作用就是防女巫攻击。
Bitbili：您提到的防女巫攻击，是否能与当前的刷空投热潮结合？
董沫：对，空投永远会有，而且以后会越来越多。刷空投这个事情，Brevis 能够给用户一个空投的「护身符」，也就是参与空投的人首先要在 Brevis 这里获取认证。我们不需要知道你是谁，但是通过链上的方式能够证明你是大户或者 OG 才行。
因为真正的「老地址」是装不出来的，链上过去所有的交互行为都是没办法做假的，比如当一个地址的历史数据显示它已经被 MEV 攻击过 5 次，那他怎么可能还是一个机器人呢？再比如，你曾经是 Crypto Punk 的持有者，那么作为曾经支持过生态的老用户，你也应该获得相应的 Reward。
「Brevis 不是一个产品，而是平台」
最后，我们也就 ZK 技术的发展现状、Brevis 当前和未来的开发重点，以及 Brevis 的经济模型几个问题，向董沫博士征询了答案。
Bitbili：今年，很多 ZK 生态项目都将陆续上线主网。但此前 Arbitrum 创始人 Ed Felten 曾说：ZK 是未来的解决方案，而且永远都只会是未来的解决方案。您怎么看待这种观点？ZK 技术真的成熟了吗？
董沫：Celer 很早就在做 ZK 技术产品，但是我们当时觉得不是一个很好的时机，主要是因为整个 ZK 的开发者生态、开发者工具链都还是很早期的，我们也想要等待这个生态更加成熟。但从去年底开始，ZK 生态大概达到了所谓的转折点。这个转折点主要是在于 ZK 的开发框架和基础性能迅速提升，使我们可以更好地去 Build。其实现在 ZK 技术相对来说已经 Ready 了，但是它仍然很年轻，比如说审计，能够审计 ZK 的团队基本没有几个。不过 ZK 生态的实际情况并没有 Ed 说的那么悲观。
Bitbili：Brevis 现在最主要的开发工作是什么？
董沫：目前我们需要做的就是丰富 ZK Query Engine。比如说我刚才提到的 zkDID 的 Query Engine、DeFi Trading 的 Query Engine 等几套工具。我们不光是要做几个 Engine，而是要做出一套 SDK，能够让开发者更好、更方便地根据自己需求去开发新的 ZK Query Engine。
其实我刚才提到的 zkDID、数据驱动型 DeFi 等，这些都是我们自己能想到的一些应用场景，但是我们相信社区和开发者肯定能想到比这更加激动人心的东西。所以 Brevis 不是一个单独的产品，而是一个平台，能够让开发者不断地 Plug In 新的东西，去 Query 自己想要的东西，而不要受我们预设的限制。这是我们希望要去做的事情。
Bitbili：Brevis 会采用新的经济模型吗？
董沫：我们现在主要的精力都专注在技术上，至少要先把整个工具套件长什么样先做出来，现在来看 Brevis 的经济模型具体是什么样还不确定。
文章来源于互联网:专访Celer董沫博士：Brevis如何为智能合约「开天眼」