SevenX Ventures: Uniswap V4后，协处理器有多大的应用空间？

本文为 SevenX 研究团队原创，仅供交流学习，不构成任何投资参考。如需引用，请注明来源。

原版英文报告于 2023 年 6 月发表于 SevenX 的  Mirror  平台。更多中文投研内容，请关注公众号【SevenXVentures】。

作者：Hill

近期，Uniswap v4发布，尽管功能尚不完备，但我们希望社区能够广泛探索前所未有的可能性。考虑到可能会有大量文章介绍 Uniswap v4在 DeFi 领域的巨大影响力，因此本文将探讨 Uniswap v4如何激发新型区块链基础架构：协处理器(Coprocessor)。

Uniswap v4简介

正如其白皮书所述，Uniswap v4主要有 4 项改进：

• 钩子（Hook）：钩子是外部部署型合约，在池子执行期间的指定点执行开发者定义的逻辑。通过这些钩子，集成者能够创建灵活且可自定义执行的集中流动性池。

• 单例（Singleton）：Uniswap v4采用单例设计模式，其中所有池均由单个合约管理，使池部署成本降低了 99% 。

• 闪电记账（Flash Accounting）：每个操作都会更新一个内部净余额，也称为增量，仅在锁定结束时进行外部划转。闪电记账简化了复杂的池操作，例如原子交换和添加。

• 原生 ETH：支持 WETH 和 ETH 交易对。

节省的大部分 gas 费得益于后 3 项改进，但毫无疑问，最令人兴奋的新特性肯定是本文一开始提到的全新亮点：钩子。

钩子让流动性池更加复杂、更加强大

Uniswap v4的主要增强功能围绕着钩子解锁的可编程性。此特性让流动性池更加复杂、更加强大，使其比以往任何时候都更加灵活、可自定义程度更高。与 Uniswap v3的集中流动性（Uniswap v2的净升级）相比，Uniswap v4的钩子为流动性池的运行方式提供了更广泛的可能性。

此版本可以视为 Uniswap v3的净升级，但在实际实施时可能并非如此。与 Uniswap v2池相比，Uniswap v3池始终是种升级，因为在 Uniswap v3中可以执行的“最差”升级就是将流动性“集中”在整个价格范围内，其运行原理与 Uniswap v2相同。然而，在 Uniswap v4中，流动性池的可编程程度可能不会带来良好的交易或流动性提供体验，可能会出现错误，并且会出现新的攻击媒介。由于流动性池的运行方式发生了诸多变化，希望利用钩子特性的开发者必须谨慎行事。他们需要彻底了解其设计选择对池功能的影响以及流动性提供者的潜在风险。

Uniswap v4中引入钩子意味着代码在区块链上的执行方式发生了重大转变。传统上，区块链代码以预定的顺序方式来执行。然而，钩子允许更灵活的执行顺序，以确保某些代码在其他代码之前执行。此特性将复杂的计算推向堆栈的边缘，而不是在单个堆栈中加以解决。

从本质上来说，钩子支持在 Uniswap 原生合约之外执行更复杂的计算。虽然在 Uniswap v2和 Uniswap v3中,可以通过 Uniswap 之外的手动计算并通过其他智能合约等外部激活器触发来实现此特性，但 Uniswap v4将钩子直接集成到了流动性池的智能合约中。与之前的手动流程相比，这种集成使流程更加透明、可验证且去信任。

钩子带来的另一个好处是可扩展性。Uniswap 现在不再需要依赖新的智能合约（需要流动性迁移）或分叉来部署创新。钩子现在可直接实现新功能，让旧流动性池焕然一新。

Uniswap v4流动性池的今天，就是其他 dApp 的明天

据我预计，会有越来越多的 dApp 像 Uniswap v4一样将计算推到自己的智能合约之外。

Uniswap v4如今的运行方式是允许在任何步骤拆分流动性池执行，可以插入任意条件，并触发 Uniswap v4合约之外的计算。到目前为止，唯一类似的情况是闪电贷，如果未在同一区块内归还贷款，则恢复执行。只是计算仍然发生在闪电贷合约中。

Uniswap v4的设计带来了许多在 Uniswap v3中无法实现或实现效果不佳的优势。例如，现在可以使用嵌入式预言机，从而减少对经常引入潜在攻击媒介的外部预言机的依赖。这种嵌入式设计增强了价格信息的安全性和可靠性，这是 DeFi 协议得以运行的关键因素所在。

此外，以前必须从外部触发的自动化现在可以直接嵌入到流动性池中。这种集成不仅缓解了安全问题，还解决了与外部触发器相关的可靠性问题。此外，还让流动性池能够更加流畅且高效地运行，增强了其整体性能和用户体验。

最后，通过 Uniswap v4中引入的钩子，可以直接在流动性池中实现更多样化的安全功能。过去，流动性池采用的安全措施主要是审计、漏洞奖励和购买保险。借助 Uniswap v4，开发者现在可以直接在池子的智能合约中设计和实施各种失效安全机制和低流动性警告。这一发展不仅增强了池子的安全性，还为流动性提供者提供了更高的透明度和控制力。

与传统手机相比，智能手机的优势在于可编程性。智能合约长期以来一直生活在“持久脚本”的阴影之下。如今，借助 Uniswap v4的优势，流动性池智能合约得到了全新的可编程升级，变得“更智能”。我想不通，既然有机会从诺基亚升级到 iPhone，为什么不是所有 dApp 都想朝着这个方向升级。由于诺基亚比 iPhone 更可靠，因此我能理解一些智能合约希望保持现状，但我说的是 dApp 未来的发展方向。

dApp 希望使用自己的“钩子”，这就存在扩展问题

想象一下将其应用于所有其他 dApp，我们可以在其中插入要触发的条件，然后在原始交易序列之间插入任意计算。

这听起来像是 MEV 的运行原理，但 MEV 并不是面向 dApp 开发者的开放设计空间。这更像是一次未知的黑暗森林徒步，充其量也就是寻求外部 MEV 保护，然而却只能寄希望于最好的结果。

假设 Uniswap v4的灵活性激发了新一代 dApp（或从现有 dApp 升级）采用类似的理念，使其执行序列具有更高的可编程性。由于这些 dApp 通常仅部署在一条链（L1或L2）上，因此我们预计大多数状态更改都在该链上运行。

• 在 dApp 状态更改过程中插入的额外计算可能过于复杂且繁琐，无法在该链上运行。我们可能很快就会超出 Gas 限制，或者根本就难以实现。此外，还会带来诸多挑战，特别是在安全性和可组合性方面的挑战。

• 并非所有计算都是平等的。dApp 对预言机和自动化网络等外部协议的依赖就证明了这一点。然而这种依赖可能会带来安全风险。

总结一下问题：将所有计算都整合到一条单链上的更改状态的智能合约执行里来，远非最佳方式。

解决方案提示：在现实世界中已经得到解决

为了解决新一代 dApp 带来的这个问题（可能很大程度上受到 Uniswap v4的启发），我们必须深入研究问题的核心：这一条单链。区块链运行方式如同分布式计算机，用一个 CPU 处理所有任务。在个人电脑上，现代 CPU 已经在解决这一问题上取得了长足的进步。

正如计算机从单核单片 CPU 过渡到由多个效率核心、性能核心、GPU 和 NPU 组成的模块化设计。

dApp 计算也可以以类似的方式进行扩展。通过将处理器专业化并结合其成果，将一些计算外包到主处理器之外，即可实现灵活性、最优性、安全性、可扩展性和可升级性。

实际解决方案

实际上只有两类协处理器：

• 外部协处理器

• 嵌入式协处理器

外部协处理器

外部协处理器类似云端 GPU，很好用、很强大，但是 CPU 和 GPU 通信之间存在额外的网络延迟。此外，GPU 最终并非由你来控制，因此你就必须相信它正在正确地完成工作。

以 Uniswap v4为例，假设在最后 5 分钟 TWAP 时将一些 ETH 和 USDC 添加到流动性池中，如果 TWAP 计算在 Axiom 中完成，则 Uniswap v4基本上是使用以太坊作为主处理器，Axiom 作为协处理器。

Axiom

Axiom 是以太坊的 ZK 协处理器，它为智能合约提供对所有链上数据的去信任访问以及对数据进行任意表达式计算的能力。

开发者可以对 Axiom 进行查询，并在其智能合约中以去信任方式使用链上经过零知识（ZK）验证的结果。要完成查询，Axiom 会执行三个步骤：

• 读取：Axiom 使用零知识证明，以去信任方式更正任何历史以太坊区块中的区块头、状态、交易和收据的读取数据。所有以太坊链上数据都以其中一种形式进行编码，这意味着 Axiom 可以访问存档节点可访问的任何数据。

• 计算：获取数据后，Axiom 就会据此应用经过验证的计算基元。这包括从基本分析（求和、计数、最大值、最小值）到加密（签名验证、密钥聚合）和机器学习（决策树、线性回归、神经网络推理）的各种操作。每一次计算的有效性都将在零知识证明中得到验证。

• 验证：Axiom 为每个查询的结果附带零知识有效性证明，证明（1）已从链上正确获取输入数据，并且（2）已正确应用计算。该零知识证明在 Axiom 智能合约中进行链上验证，然后最终结果以去信任方式供所有下游智能合约使用。

Warp 合约（通过RedStone）

Warp 合约是最常见的 SmartWeave 实现，该体系结构旨在在 Arweave 上创建可靠、快速的生产就绪型智能合约平台/引擎。实质上，SmartWeave 是 Arweave 交易的有序数组，受益于 Arweave 上交易区块收录（Block Inclusion）费用市场的缺失。这些独特的属性允许无限的交易数据，除了存储成本之外，无需额外费用。

SmartWeave 采用一种称为“惰性评估”的独特方法，将执行智能合约代码的责任从网络节点转移给智能合约的用户。从本质上讲，这意味着交易验证的计算被推迟到需要时为止，减少了网络节点的工作负载，并能够更有效地处理交易。通过这种方法，用户可以根据需要执行尽可能多的计算，而不会产生额外费用，从而提供其他智能合约系统无法实现的功能。显然，尝试在用户的 CPU 上评估具有数千次交互的合约终究是徒劳的。为了克服这一挑战，开发了一个抽象层，例如 Warp 的 DRE。该抽象层由处理合约计算的分布式验证器网络组成，最终可显著缩短响应时间，改善用户体验。

此外，SmartWeave 的开放式设计使开发者能够用任何编程语言编写逻辑，为常常僵化的 Solidity 代码库提供了一种全新的替代方案。通过将某些高成本或高吞吐量的操作委托给 Warp，无缝的 SmartWeave 集成可增强基于 EVM 链构建的现有社交图谱协议，从而充分利用这两种技术的优势。

Hyper Oracle

Hyper Oracle 是专为区块链设计的 ZK 预言机网络。目前，ZK 预言机网络仅面向以太坊区块链运行。它使用 zkPoS 从区块链的每个区块检索数据，并将其作为数据源，同时使用在 zkWASM 上运行的可编程 zkGraph 处理数据，所有这些操作都以去信任且安全的方式进行。

开发者可以使用 JavaScript 定义自定义链下计算，将这些计算部署到 Hyper Oracle 网络，并利用 Hyper Oracle Meta Apps 来索引和自动化其智能合约。

Hyper Oracle 的索引和自动化 Meta Apps 完全可自定义且十分灵活。可以定义任何计算，并且所有计算（甚至机器学习计算）都将通过生成的零知识证明来加以保护。

• 以太坊区块链是 ZK 预言机的原始链上数据源，但将来任何网络都可以使用。

• Hyper Oracle ZK 预言机节点包含两个主要组件：zkPoS 和 zkWASM。

  - zkPoS 通过使用零知识来证明以太坊的共识，获取以太坊区块链的区块头和数据根。零知识证明生成过程可以外包给去中心化的证明者网络。zkPoS 充当 zkWASM 的外部环路。

  - zkPoS 将区块头和数据根提供给 zkWASM。zkWASM 将此数据作为运行 zkGraph 的基本输入。

  -zkWASM 运行自定义的数据映射或 zkGraph 定义的任何其他计算，并生成这些操作的零知识证明。ZK 预言机节点的操作员可以选择他们希望运行的 zkGraph 数量（从一个到全部已部署的 zkGraph）。零知识证明生成过程可以外包给去中心化的证明者网络。

• ZK 预言机输出的是链下数据，开发者可通过 Hyper Oracle Meta Apps 使用该链下数据（将在后续章节中介绍）。该数据还附带证明其有效性和计算情况的零知识证明。

其他值得一提的项目

如果您决定采用这种方式，还有一些项目可以用作外部协处理器。只是这些项目在区块链基础架构的其他垂直领域有所重合，没有被单独地归类为协处理器。

• RiscZero：如果 dApp 使用 RiscZero 计算链上代理的机器学习任务，并将结果提供给 StarkNet 上的游戏合约，则会使用 StarkNet 作为主处理器，使用 RiscZero 作为协处理器。

• IronMill：如果 dApp 在 IronMill 中运行 zk 环路，但在以太坊上部署智能合约，则会使用以太坊作为主处理器，使用 IronMill 作为协处理器。

外部协处理器的潜在用例

• 治理和投票：历史链上数据可以帮助去中心化自治组织（DAO）记录每个成员拥有的投票权数量，这对投票来说必不可少。如果没有这些数据，成员可能无法参与投票过程，这可能会阻碍治理。

• 承销：历史链上数据可以帮助资产管理人评估其管理人除利润之外的业绩。他们可以查看所承受的风险水平和所经历的回撤类型，这有助于他们在补偿或潜在奖励减少时做出更明智的决策。

• 去中心化交易所：链上的历史价格数据可以帮助去中心化交易所根据过去的趋势和模式进行交易，可能为用户带来更高的利润。此外，历史交易数据可帮助交易所改进算法和用户体验。

• 保险产品：保险公司可以使用历史链上数据来评估风险，并为不同类型的保单设定保费。例如，在为 DeFi 项目设定保费时，保险公司可能会查看过去的链上数据。

请注意，以上所有用例都是异步用例，因为客户 dApp 在区块 N 中触发时需要调用外部协处理器的智能合约。当协处理器返回计算结果时，必须至少在下一个区块（即 N+ 1）中以某些形式接受或验证结果。这样一来，至少得到下一个触发区块才能利用协同处理结果。这种模式真的很像云端 GPU。它可以很好地运行您的机器学习模型，但由于延迟，您无法在上面愉快地玩快节奏游戏。

嵌入式协处理器

嵌入式协处理器类似个人电脑主板上的 GPU，位于 CPU 旁边。GPU 与 CPU 的通信延迟非常小。而且 GPU 完全受您控制，因此您可以非常确定它没有被篡改。只是要让它像云端 GPU 一样迅速地运行机器学习，需要付出高昂的成本。

仍以 Uniswap v4为例。假设在最后 5 分钟 TWAP 时将一些 ETH 和 USDC 添加到 Artela 上部署的流动性池中，如果该池部署在 Artela 上的 EVM 中，并且 TWAP 计算在 Aretla 上的 WASM 中完成，则该池基本上是使用 Artela 的 EVM 作为主处理器，Artela 的 WASM 作为协处理器。

Artela

Artela 是使用 Tendermint BFT 构建的L1。它提供了一个框架，支持任意执行层的动态扩展，以实现链上自定义功能。每个 Artela 全节点同时运行两个虚拟机。

• EVM，存储和更新智能合约状态的主处理器。

• WASM，存储和更新 Aspect 状态的协处理器。

Aspects 代表开发者希望在不触及智能合约状态的情况下运行的任意计算。可将其视为一个 Rust 脚本，为 dApp 提供超出智能合约原生可组合性的自定义功能。

如果这一点不好理解，可以试试从以下两个角度来看：

• 从区块链体系结构的角度

  - Aspect 是新的执行层。

  - 在 Artela 中，区块链同时运行两个执行层——一个用于智能合约，一个用于其他计算。

  - 这个新的执行层不会引入新的信任假设，因此不会影响区块链本身的安全性。两个虚拟机均由运行相同共识的同一组节点保护。

• 从应用程序运行时的角度

  - Aspects 是与智能合约协同工作的可编程模块，支持添加自定义功能和独立执行。

  - 它在几个方面比单一智能合约更具优势：

  -- 非侵入性：无需修改智能合约代码，即可在合约执行前后进行干预。

  -- 同步执行：支持钩子逻辑贯穿整个交易生命周期，允许精细化自定义。

  -- 直接访问全局状态和基础层配置，支持系统级功能。

  -- 弹性区块空间：为交易吞吐量要求较高的 dApp 提供有协议保障的独立区块空间。

  -- 与静态预编译相比，支持 dApp 在运行时实现动态和模块化升级，以平衡稳定性和灵活性。

通过引入这种嵌入式协处理器，Artela 取得了令人兴奋的突破：如今，任意扩展模块 Aspects 可以通过与智能合约相同的交易来执行。开发者可以将其智能合约绑定到 Aspects，并让调用智能合约的所有交易都由 Aspects 来处理。.

此外，与智能合约一样，Aspects 在链上存储数据，支持智能合约和 Aspects 读取彼此的全局状态。

这两个特性极大提升了智能合约和 Aspects 之间的可组合性和互操作性。

• Aspect 功能：

  与智能合约相比，Aspects 提供的功能主要侧重在交易前和交易后执行。Aspects 不会取代智能合约，而是对其进行补充。与智能合约相比，Aspects 为应用程序提供了以下独特功能：

  - 自动将可靠的交易插入到颠倒的区块中（例如，用于计划的任务）。

  - 交易引起的状态数据变化的反转（只有授权的合约交易才可以反转）。

  - 读取静态环境变量。

  - 将临时执行状态传递到下游的其他 Aspects。

  - 读取从上游 Aspect 传递的临时执行状态。

  - 动态和模块化的可升级性。

• Aspect 和智能合约的区别：

  Aspect 与智能合约的区别在于：

  - 智能合约是带有代码的账户，而 Aspect 是区块链的原生扩展。

  - Aspect 可以在交易和区块生命周期的不同点运行，而智能合约仅在固定点执行。

  - 智能合约可以访问自己的状态和区块的有限上下文，而 Aspect 则可以与全局处理上下文和系统级 API 进行交互。

  - Aspect 的执行环境是为接近原生速度而设计。

  Aspect 只是代码逻辑片段，与账户无关，因此无法：

  - 写入、修改或删除合约状态数据。

  - 创建新合约。

  - 划转、销毁或持有原生代币。

这些 Aspect 使 Artela 成为一个独特的平台，可以扩展智能合约的功能，并提供更全面、可自定义程度更高的开发环境。

*请注意，严格来说，上述 Aspect 也称为“内置”Aspect，它是由 Artela Chain 全节点运行的嵌入式协处理器。dApp 还可以部署自己的异构 Aspect，由外部协处理器运行。这些外部协处理器可以在外部网络上执行，也可以由另一个共识中的节点子集执行。它更加灵活，因为 dApp 开发者实际上可以用它执行任何想执行的操作，只要这种操作是安全且合理的。目前仍在探索之中，具体细节尚未公布。

嵌入式协处理器的潜在用例

• 新 DeFi 项目中涉及的复杂计算（例如复杂的博弈论机制）可能需要嵌入式协处理器具有灵活性和迭代性更高的即时计算能力。

• 针对各类 dApp 更灵活的访问控制机制。目前，访问控制通常仅限于基于智能合约权限的黑名单或白名单。嵌入式协处理器可以解锁即时且精细的访问控制级别。

• 全链游戏（FOCG）中的某些复杂功能。FOCG 长期以来一直受到 EVM 的限制。如果 EVM 保留划转 NFT 和代币等更简单的功能，而其他逻辑和状态更新由协处理器来计算，那么情况可能会更简单。

• 安全机制。dApp 可以引入自己的主动安全监控和失效安全机制。例如，流动性池可以阻止每 10 分钟超过 5% 的提现。如果协处理器检测到其中一笔提现，智能合约可以停止并触发一些警报机制，例如在某个动态价格范围内注入紧急流动性。

结束语

dApp 变得庞大、臃肿且过于复杂不可避免，因此协处理器的普及也是必然。这只是时间和采用曲线的问题。

运行外部协处理器可以让 dApp 留在自己的舒适区：无论以前位于哪条链上。然而，对于寻找可部署执行环境的新 dApp 开发者来说，嵌入式协处理器就像个人电脑上的 GPU。如果自称高性能个人电脑，就必须拥有像样的 GPU。

遗憾的是，上述项目尚未在主网上线。我们无法真正进行基准测试，无法展示哪一个项目更适合哪种用例。然而，有一件事毋庸置疑，那就是技术呈螺旋式上升。看起来我们是在原地兜圈子，但请记住，从侧面看，历史将见证技术真的在发展。

可扩展性不可能三角万岁，协处理器万岁。