Celer宣布推出ZK全链数据计算和验证平台Brevis

TL; DR

众所周知，Web2 应用通常像一个个被围墙隔离起来的花园，独立运行，这导致了其数据互操作性受限、用户锁定和身份碎片化等问题。基于区块链构建的 Web3 去中心化应用 (dApps）确实可以解决这些问题。 然而，作为 dApp 核心的智能合约目前无法以去信任的方式来访问和利用存储在多个区块链完整历史中的大量数据。

为了解除这个限制，我们推出了 Brevis ， 一个 ZK 全链数据计算和验证平台，它使 dApp 能够以完全去信任的方式访问、计算和利用跨多个区块链的任意数据。

图 1. Brevis 架构

Brevis 的架构包括三个组件：zkFabric、zkQueryNet 和 zkAggregatorRollup。

zkFabric 从所有连接的区块链中收集「区块头」，通过 ZK 轻客户端电路证明其有效性后，生成共识证明。该组件对于 dApps 以去信任的方式自由访问「区块头」以及受支持区块链的所有状态至关重要。

zkQueryNet 是一个提供 ZK 查询引擎的开放市场 ，可直接接受来自链上智能合约的数据查询，并通过 ZK 查询引擎电路生成查询结果和相应的 ZK 查询证明。其中一些引擎提供高度专业化的查询，例如计算可配置时间段内的 dex 交易量；另一些引擎高度通用化，支持数据索引抽象和高级查询语言，以满足各种应用需求。

zkAggregatorRollup 是一个专门的 ZK rollup，充当 zkFabric 和 zkQueryNet 的聚合和存储层。 它验证来自这两个组件的证明，存储证明数据，并将其 zk 证明状态根提交给所有连接的区块链，允许 dApp 直接在自身链上智能合约的业务逻辑中访问证明查询结果。

通过这种 模块化 架构，Brevis 可以为链上智能合约提供 完全 去信任 、灵活且高效 的 全链 数据访问和计算能力。 Brevis 解锁了 全新的 dApp 开发范式 ，支持广泛的 用例 ，例如 数据驱动型 DeFi、zk 跨链桥、链上用户获取、zkDID、社交帐户抽象化 等等。

在 Brevis 最初的概念验证中，我们用 gnark 在 zkFabric 中构建了一些当前运行最快的 ZK 轻客户端电路 ， 用于 Ethereum PoS、Cosmos 和 BNB Chain，使任何 EVM 和非 EVM 链能够以 完全去信任 的方式访问这三条链的状态。

表 1 总结了一些关键电路性能基准数据（数据由 20 核、 2.3 GHz、 384 GB 内存的 Linux 服务器取得，测试未使用 GPU 加速）。 使用这些 ZK 轻客户端电路，我们实现了一个面向用户、支持 Ethereum Goeril 和 BNB Chain 之间跨链的 资产 zkBridge 。

表 1 - ZK 轻客户端电路性能测评

(Linux 服务器/ 20 核/@ 2.3 GHz /384 GB 内存)

想要深入了解 Brevis，请继续阅读本文。欢迎参阅 Brevis 白皮书 ，获取全面的技术信息。

Web3.0 dApp 正在错失全链数据的潜在价值

Web 2.0 应用彻底改变了互联网用户的交互和内容生成模式。 然而，这些应用通常像被围墙隔离开的花园一样单独运作，用户数据存储在由平台供应商控制的中心化数据库中。 这导致了数据互操作性受限、身份碎片化、金融和社交数据锁定等诸多问题，从而导致了创新受阻、供应商锁定、隐私滥用和用户体验碎片化等后果。

构建在区块链上的 Web3 去中心化应用 (dApp) 将能够打破这些信息孤岛，这是因为区块链的数据存储仅允许在原有基础上添加新信息，且所有数据可公开访问。 随着多链生态扩展，也因为 dApp 的日益普及，L1 区块链和 L2 rollup 积累了丰富的原始数据—例如资产转移、合约函数调用、合约内事件 和区块链状态根，这些数据将使我们能够提取有价值的信息，例如资产所有权、用户活动概况、社交图谱、金融联系、市场价格趋势、交易量等。

许多链下产品和项目已经在利用可公开访问数据存储的以上特性 — Dune Analytics 和 Graph 等产品能够为区块链应用提供跨时间段的链下数据索引或数据分析。 它们还可为 dApp 的前端 UI 提供状态数据，例如用户交易历史记录。 这些应用以链下方式访问区块链数据，通过区块链节点的 RPC 端口记录、索引和计算数据。

很自然，我们会认为 链上 区块链应用或智能合约应该能够以完全去信任的方式，在其业务逻辑中轻松访问和利用这些全链数据，毕竟，这些 dApp 是区块链内部的「原生居民」。

然而，事实并非如此。

事实上， Web3 dApp 无法以完全去信任的方式访问存储在区块链中的绝大部分数据。 这是因为部署在单个区块链上的智能合约存在 于区块链虚拟机这一场景中，因此只能通过以下方式访问数据：

• ( 1) 通过其他智能合约明确定义的接口；

• ( 2) 数据须在 dApp 本身所在的区块链上；

• ( 3) 只能获得当前状态，无法获得完整的历史数据。

有人可能会说，有一些方案理论上是可以解决上述问题的，例如直接在智能合约中解析和计算数据查询语义，或者使用基于纯智能合约、去信任的轻客户端来验证共识算法。然而，由于高昂的链上计算成本，这些方法实际并不可行。我们可以使用链下预言机，但它们需要依赖预言机本身的外部安全性来确保数据有效性。

那么，我们怎么让智能合约访问和计算任何区块链内任意时间段的数据呢？

零知识简洁证明：计算迁移的魔法

零知识简洁证明技术 (ZKP) 是密码学中的一个新兴领域，有可能改变我们的数字交互模式。 它允许一方向另一方证明计算的有效性，而无需透露有关输入值的 任何 信息。 验证方只需要运行一个计算成本低廉的程序（称为验证程序）来确认计算的准确性。

ZKP 不仅能提供隐私保护，还可以将计算从高单位成本方迁移至低单位成本方。 证明者通过执行昂贵的计算操作来完成计算并生成密码证明，而验证者运行成本较低的操作来验证证明。 这个过程将产生大量计算的位置从验证者转移到证明者，如果证明者的单位计算成本远低于验证者的计算成本，那么对于整个证明系统来讲这将是一个更高效的处理方式。 这种计算迁移属性是许多 ZK rollup 的驱动力，我们也将利用此属性来设计 Brevis。

Brevis 系统概述

如图 1 所示，Brevis 的架构包含三个主要组件：zkFabric、zkQueryNet 和 zkAggregatorRollup。 zkFabric 从所有连接的区块链中收集「区块头」，并生成证明其有效性的 ZK 共识证明。 这些「区块头」经过进一步的 zk 验证，存储在 zkAggregatorRollup 中。 zkQueryNet 接受来自 dApp 的数据查询，并根据存储在 zkAggregatorRollup 中已经证明的「区块头」生成 ZK 查询证明。 这些查询结果经过 zk 验证后，也会存储在 zkAggregatorRollup 中。

本质上，zkAggregatorRollup 是一个 ZK rollup，充当 zkFabric 和 zkQueryNet 的聚合和存储层。 通过提交 zk 证明过的状态根至所有 Brevis 连接的区块链，zkAggregatorRollup 允许 dApp 访问已经证明的查询结果，并以去信任的方式直接在其链上智能合约逻辑中加以使用。

了解整体概述后，我们现在详细解析每个组件。

首先，为了利用多链上的任意数据，dApp 需要以一种去信任的方式访问其本地链以外的其他链的「区块头」。 这是因为「区块头」包含可用于访问区块链中数据和状态的状态根。 为了满足这一需求，我们引入了 zkFabric 来为所有支持的链的「区块头」生成 ZK 共识证明。 一个轻客户端电路会生成共识证明，证明所验证的「区块头」是根据相应区块链的共识规则生成的。zkFabric 本身是一个去中心化系统，由「区块头」中继器和证明者网络组成。

为了从已经 zk 证明的「区块头」中提取有价值的信息，我们搭建了 zkQueryNet ，一个提供各式 ZK 查询引擎的开放市场 ，dApp 开发者和智能合约可直接与其交互 。 dApp 开发者可以选择符合自己需求的 ZK 查询引擎，并通过智能合约中的高级 API 编写查询请求。

运行期间，智能合约可以针对特定的 ZK 查询引擎调用 zkQueryNet 的代理智能合约。 该 ZK 查询引擎的证明者将接收此查询请求。 ZK 查询引擎使用 zkFabric 提供的已经 zk 证明的 「区块头」，计算查询结果并生成 ZK 查询证明，证明计算已正确完成。

不同的 ZK 查询引擎可以提供各式各样的 API，可以是通用查询语言，也可以是具有固定参数的高度具体的函数调用。例如，在服务非常具体的查询请求的用例中，一个 ZK 查询引擎可能只公开一个接受两个区块编号和两个链 ID 的函数，用以查询 Uniswap 上指定时间段内这两条区块链上  ETH/USDC 交易对的加权平均价格 。另一方面，通用的 ZK 查询引擎可以使用高级数据库查询语言（例如 SQL 或 GraphQL）给开发者提供区块链索引抽象，这会非常类似于链下数据解决方案（如 Dune Analytics 和 Graph）中执行的操作。

Brevis 将提供一组 ZK 查询引擎，以合理的灵活性和高性能解决许多现存用例。由于 zkQueryNet 是一个开放的市场，我们期望 dApp 开发者和第三方平台也能提供其他 ZK 查询引擎，以更好地服务多样化的应用生态。

最后， zkAggregatorRollup 是由轻量级 ZK 虚拟机提供支持的 ZK rollup 区块链，它汇总了来自 zkQueryNet 和 zkFabric 的不同证明和输入信息。具体而言，zkAggregatorRollup VM runtime 具有以下功能：

• （1 ）递归验证由 zkQueryNet 和 zkFabric 生成的证明；

• （2 ）存储来自 zkFabric 的已由 zk 验证的区块头 ；

• （3 ）存储查询请求和 zk 验证结果。

在接入一个新的 ZK 查询引擎或添加新的共识类型时，zkAggregatorRollup 将扩展支持相应的 ZK 证明验证。此外，许多 ZK rollup 链仅将其状态根级数证明提交给单个区块链，zkAggregatorRollup 的不同之处在于，它会将其状态根证明提交给 Brevis 支持的所有区块链 。

因为 zkAggregatorRollup 支持的所有链上均有其状态根，智能合约可以通过数据包含证明获取查询结果和区块头。使用 zkAggregatorRollup 作为聚合点的主要好处是将区块头通信或验证成本从 O(N^ 2) 减少到 O(N)（其中 N 是 Brevis 支持的区块链数量），并在所有连接的区块链之间高效地按需分享查询结果。

综上所述，Brevis 具有以下主要优势：

• 去信任： Brevis 不依赖任何链下方来证明数据和计算的完整性； 相反，它仅依赖于 ZK 简洁证明。 因此，使用 Brevis 的应用除了信任底层区块链和密码学协议外，无需接受任何额外的信任假设；

• 全链支持： Brevis 可集成基于不同共识机制运行的多个区块链，以支持全链数据访问和计算；

• 模块化： Brevis 在其 zkQueryNet 中进行了高度模块化的设计，因此可以通过搭建不同的 ZK 查询引擎满足不同受众和设计的广泛应用需求；

• 低成本： Brevis 的 zkAggregatorRollup 本质上是区块头和查询结果的批处理和聚合层。 因此，zkAggregatorRollup 通过消除 N 对 N 通信成本、共享跨链和跨应用查询结果，显着降低了链上成本。

值得注意的是，Brevis 与 Dune Analytics 和 Graph 等链下数据索引解决方案之间的主要区别在于， Brevis 可以生成已经 zk 证明的查询结果，链上智能合约的业务逻辑可以去信任的方式直接使用这些查询结果，而链下解决方案的数据结果只能用于基于 web2 的数据分析情境之中。

用例演示

图 2 - 用例演示

在讨论广泛的用例之前，我们提供了一个具体的应用示例来概述 Brevis 的工作流程。 注意，此概述抽象了一些关键细节，我们建议读者参阅完整的白皮书以获取详细信息。

像 PancakeSwap 这样部署在多链上的去中心化交易所 (DEX) 通常需要根据交易对质量得分（例如平均每日交易量、 14 天交易量、价格波动、活跃交易用户数量和活跃流动性提供者数量）动态调整所有链上流动性池的奖励。

目前，此类调整必须通过社区治理建议进行，这需要大量的人力开销，并且只能在奖励设置严重偏离最佳方案时才能完成。 这种次优奖励配置，通常落后于市场趋势，并会导致用户参与度下降、收益损失和资金库预算浪费。

Brevis 使 DEX 能够根据当前全链市场趋势，通过程式化和去信任的方式调整流动性激励计划，以应对这些挑战。 为简单起见，假设我们只想获取交易量这一数据，并且在 zkQueryNet 中有一个 ZK 查询引擎 ?，它为 DEX 交易量数据提供了一组高度优化的电路，其 API 如下所示：

上文图 2 显示了此用例运行的分步流程。 要使用这个数据计算 API，DEX 智能合约首先需要用上述查询参数调用 zkQueryNet 的代理智能合约（记为?）。 请注意，此函数是异步的，只会立即返回一个 ?????_??，因此 DEX 的智能合约会记住此 ID，并还会提供一个处理程序来稍后处理返回值。

这个函数调用随后被 ? 的证明者 ?_? 所捕获。?_? 使用 ?ℎ???_?? 已经在 zkAggregatorRollup 中验证并存储的区块头来证明 DEX 的 ???????_???? 在指定时间段内从 ?????_????? 到 ???_?????，确实有 ??????，并生成一个 ZK 证明 ?。

? 的证明验证器在 zkAggregatorRollup 中验证 ? 和 ?????? 结果，并将相应的查询参数都存储在 zkAggregatorRollup 中。此状态随后会被包含在 zkAggregatorRollup 的状态根 ? 中，并提交到 DEX 部署的链上。

现在，? 可以通过使用 ? 的状态包含证明 来获取和验证查询结果，然后将获取到的查询结果返回给 DEX 的智能合约处理函数。处理函数能够将存储的 ?????_?? 与返回的查询结果进行匹配，并根据成交量数据相应地调整流动性激励计划。

zkFabric 概念证明：Ethereum PoS、Cosmos Tendermint、BNB Chain Light Client ZK Circuits 以及 ZK Bridge

几乎所有现存的互操作性解决方案都属于「外部验证模型」，需要信任一个中间实体。虽然理论上，基于链上轻客户端的解决方案是信任最小化的，但在实施起来成本太高。Brevis 通过将轻客户端协议和 ZKP 相结合来解决这一挑战，其中 zkFabric 为所有支持的区块链生成 ZK 共识证明，并将相应的区块头存储在 zkAggregatorRollup 中。在 Brevis 最初的概念验证中，我们在 Ethereum PoS、Cosmos Tendermint 和 BNB Chain 上实现了 ZK 电路的轻客户端协议。

• Ethereum PoS 轻客户端 。 EthereumPoS 轻客户端电路主要由两个子电路组成。一个是 SSZ Sync Committee Commitment 电路，用于更新 512 个当前同步委员会验证器的 SSZ 承诺，每 27 小时轮换一次。另一个是 512 个验证器的聚合 BLS 12-381 签名验证，它主要进行哈希到曲线计算，并进行 BN 254 标量域上的 BLS 12-381 配对，以便在以太坊智能合约中进行高效验证。这里，非本机配对需要大规模的非本机域 算法。通过实现各种 BLS 配对技巧并使用 gnark 提供的高效范围检查工具，我们实现了相对于现有实现最快的基于 BN 254 标量域的 BLS 12-381 签名验证。对于 SSZ Sync Committee Commitment 电路，我们正在使用查找表进行优化，并将很快发布一个优化电路。

• Cosmos Tendermint 和 BNB Chain 轻客户端。 BNB Chain 包含两层架构，包括基础层（BNB Beacon Chain -BBC）和执行层（BNB Smart Chain -BSC）。BBC 采用 Tendermint 共识，而 BSC 采用 Parli 的权威证明（PoA）共识。每个 BSC 区块由验证器集合中的某一个进行签名确认。作为专门的 Tendermint 应用，BBC 管理 BSC 验证器集合的选举和更新。每 24 小时，BBC 会通过类似 IBC 的跨链机制 （此机制早于官方 IBC 规范），选举产生一个新的 BSC 验证器集合，并将其与 BSC 同步。对于 BBC（本质上是 Tendermint），轻客户端将主要验证一批 Ed 25519 签名，而在链上直接进行这步验证的成本很高。我们在 gnark 中实现了基于 BN 254 标量域的非本机 Ed 25519 签名验证。通过 gnark 中的范围检查工具，我们实现了非本机 Ed 25519 签名验证的最高性能。对于 BSC，PoA 共识涉及 secp 256 k 1 签名验证，由于预编译的存在，直接在智能合约中验证。

上述电路已在 gnark 中部署并开源。 本篇文章开头的表格 1 已展示其基准性能。 请注意，我们正在不断优化电路，也希望在不久的将来利用硬件加速和并行化实现优化。

基于轻量级客户端，我们构建了一条支持在 Goerli 测试网和 BNB Chain 测试网之间进行双向资产转移的 ZK 资产桥 。需要注意的是，对于从 Goerli 到 BNB Chain 测试网的资产跨链，由于包括源链交易的区块头只有在 2-3 个 epoch（64-96 个区块）之后才会被最终确认并传输，所以预计的延迟时间约为 25 分钟。

基于 Brevis 的多种创新用例

除了上述 ZK Bridge 示例之外，Brevis 还可支持开发者创建 dApp，以前所未有的方式访问全链任意时间的数据。 毫无疑问，这项创新技术将建立一个新的范例，改变 dApp 在所有领域的开发方式。 在本节中，我们将展示一些可立即面市的应用，也期待社区与我们一起探索更多用例。

数据驱动型 DeFi

除了上文中探讨的流动性激励自动调整这一用例外，我们相信「数据驱动型 DeFi」将成为基于 Brevis 的广泛应用类别之一，这要归功于它的可扩展性和隐私性。

通过用去信任的方式访问所有全链交易数据及历史状态，期权等衍生品现在可以添加新的执行条件， 例如指数时间加权价格或时间-交易量加权价格 。 通过部署各种 ZK 查询引擎，一些新型的链上替代衍生品也将成为可能，它们可以跟踪用户行为、价格趋势、协议或区块链锁仓变化、波动性、价格相关性等。

链上主动型基金管理解决方案可以生成 ZK 证明，证明头寸调整完全基于市场数据的特定算法模型，没有任何未经授权的人为干预。 此外，由于 Brevis 的隐私保护特性，其可以隐藏精确的模型参数以保持竞争市场优势。

用户获取渠道去信任进行归因分成

在 Web 2.0 中，用户获取过程在用户下载或注册软件时结束，广告主为获取的用户支付固定价格，无论其留存价值如何。 这种模式对广告主和广告渠道来说都不太理想，因为前者无法区分用户价值，后者无法分享长期收益。 出现这一问题是因为获客后的用户数据只属广告主私有，渠道无法访问。

Web 3.0 可能会改变这种模式，因为大部分用户活动数据都是公开的。 然而，当前的平台仍然遵循 Web 2.0 范式。 Brevis 通过允许广告渠道为获得的用户生成 去信任的收入证明 ，彻底改变了这一困境。 这一创新技术将促使 Web 3.0 的用户获取方式发生根本性转变，广告主只为高价值用户付费，渠道也会在激励模式驱动下以最佳方式匹配用户与广告主。

ZK 去中心化身份解决方案

Brevis 是构建去信任 zkDID 解决方案的重要工具，有助于防止 Sybil 攻击并优化各种用例中的用户生命周期管理。 通过基于难以伪造的链上行为生成 ZK 证明，Brevis 使 dApp 开发者能够以完全去信任的方式运行，同时防止活动或推广 中的 Sybil 攻击。

通过利用聚合用户行为的查询结果和数据，Brevis 可以帮助构建一个去信任的用户生命周期管理流程，从而促进区块链游戏中的忠诚度系统、VIP 交易程序和 LiveOps 活动。通过 Brevis 构建的该流程与应用内记账相比具有多项优势，例如成本更低、面向未来和可移植性。 通过 Brevis 生成的 zkDID 存储在 zkAggregatorRollup 中，可供不同的应用访问。

帐户抽象

Brevis 通过提高区块链应用的安全性和可用性，在帐户抽象 (AA) 领域提供了引人注目的用例。 关键应用之一是社交账号恢复，即在用户丢失主要控制密钥的情况下，Brevis 可以帮助用户重新获得钱包访问权限。 Brevis 使智能钱包能够基于最近的交易连接而非一组固定的外部钱包来实现社交账号恢复。 这种方法减少了维护成本并降低了行业新用户的进入门槛。

Brevis 在社交和 NFT 游戏等许多其他领域也有潜在的应用。我们非常欢迎开发者探索并构建更多 Brevis 新用例！