# ZKThreads：面向 dApp 的标准零知识分片框架 By [Starknet 中文](https://paragraph.com/@starknet-zh) · 2024-05-27 --- > \*原文：[ZKThreads: A canonical ZK sharding framework for dApps](https://starkware.co/zkthreads-canonical-zk-sharding-framework-for-dapps/) \* > > _翻译及校对：_[_Starknet 中文社区_](https://twitter.com/StarkNet_ZH) > > _📑 转载请注明出处 🕹️_ 精选速览 ==== * StarkWare 与 Cartridge 推出 ZKThreads，这是一种新颖的执行分片框架，在不产生应用分化的情况下提供可扩展性和可定制性。 * ZKThreads 实现了更精简、更灵活的扩容，通过允许直接回退到基础层，确保了每一步的活跃性。 * ZKThreads 将带来更高的安全性、可组合性和互操作性，从而改善用户体验并降低交易成本。 * 首个实现案例可以在 Saya 结算服务 [GitHub 仓库](https://github.com/dojoengine/dojo/tree/main/crates/saya)中找到。 * 关于实现的更多细节，可查看 EthResearch 的[这篇文章](https://ethresear.ch/t/zkthreads-a-canonical-zk-sharding-framework-for-dapps/19619)。 简介 == 近年来，有效性（或零知识）Rollup 大受欢迎。迄今为止，从 Rollup 到协处理器以及其他分片方法，许多应用程序都依赖于内部自主开发的技术堆栈，从而导致了流动性分散、互操作性降低、用户体验不佳。 为了应对这些挑战，StarkWare 和 [Cartridge](https://cartridge.gg/) 很自豪地推出了 **ZKThreads**：一种新颖的扩容方法，为可证明应用程序实现了安全性、可组合性和互操作性之间的平衡。这一方法基于 StarkWare 在 2021 年提出的[分形扩容](https://mirror.xyz/starknet-zh.eth/-5oiKxwShIOzGUwuQJzIl070wopcPjqBcypVjRvyC1E)愿景。 在这篇文章中，我们将解释为什么需要 ZKThreads，介绍其架构设计，并最终阐述 ZKThreads 如何打开新型应用程序的大门。通过将 ZKThreads 添加到 Starknet 现有的[分形扩容技术套件](https://mirror.xyz/starknet-zh.eth/OjvxPVEUtC7_pfKHUfFYoK5yeUMv0nla94sugpvMY0s)中，Starknet 扩展了其全方位的零知识操作系统，以适应任何可证明应用程序。 为什么选择 ZKThreads? ================ 历史虽不会简单重复，但往往有迹可循。在 2015 年 11 月引入 [ERC-20 标准](https://ethereum.org/en/developers/docs/standards/tokens/erc-20/)之前，创建新的Token 或 Coin 需要构建并维护一个完整的区块链。即使你只想要一个 memecoin，你也必须在自己的区块链上进行硬分叉，并启动流动性，就像 Dogecoin 那样。在 ERC-20 标准之前推出的大多数代币现在都已灭绝，这不足为奇。 在 ERC-20 标准出现之前，代币与共识协议高度整合。转移机制并不是可以独立存在的功能。然而，ERC-20 引入了在以太坊上创建和交易代币的规范标准，而无需硬分叉和创建全新的链。一旦项目开始推出自己的  ERC-20，流动性就会集中在以太坊上。这使得构建 DEX、借贷协议、稳定币以及今天存在的整个 DeFi 生态系统成为可能。 同样，我们在可证明应用程序开发方面也面临着类似挑战。桥、Rollup 和零知识协处理器等各种应用程序都使用零知识证明，每个证明都有自己的证明库、虚拟机（VM）和技术堆栈。这些堆栈之间缺乏互操作性，操作繁琐，往往导致用户体验不尽如人意。 以零知识协处理器为例。从最简单的意义上讲，一个零知识协处理器依赖于「链下计算，链上验证」的模式，其中的「计算」可以从特定任务（例如对历史数据的计算）扩展到图灵完备的通用计算。这种模式中的「验证」指在结算层上发布零知识证明，以证明执行结果的有效性。这使得开发者能够在链下运行计算密集的程序，并在链上证明其有效性。尽管如此，零知识协处理器的设计仍然存在挑战： * **安全性**：零知识协处理器可以保证正确性证明，但无法保证活跃性（liveness）。换言之，其不能保证确实能够提供证明。 * **可组合性**：无论是通过定制的零知识库还是电路，每个技术堆栈都有自己的技术标准。这导致了不同层之间缺乏可组合性。 * **互操作性**：由于上述第一点和第二点，运行在零知识协处理器上的应用程序彼此孤立，导致流动性分散，缺乏互操作性。 相反，我们需要一个像 ERC-20 一样的通用接口来规范可证明应用程度的开发，并为需要互操作性、共享流动性和其他共享资源的应用程序打开大门。 了解 **ZKThreads** ---------------- ZKThreads 利用  Starknet  作为领先的有效性 Rollup 的地位和 Cairo 作为易证明语言的天然优势，将可证明应用程序的开发标准化，并提供以下保证： * **安全性**：ZKThreads 允许在必要时直接在 Starknet 上执行，确保每一步的活跃性和 dApp 更为精简的设计。 * **可组合性**：通过引入 ZKThread 标准，开发者得到了一个标准化、可组合的工具包，用以开发各种可证明应用程序，包括原生桥、共同的数据可用层和安全机制。 * **互操作性**：所有使用 ZKThread 标准的应用程序都将实现本地互操作，从而最大限度地减少碎片化，并开辟大量新的使用案例。 ZKThreads 如何运行？ =============== ZKThreads 架构的总体目标是让可证明应用程序在性能、可组合性和互操作性之间取得平衡。从架构上讲，它由以下部分组成 * **ZKThread** — 包括批「处理器」、证明器和合约。 * **ZKThread 验证器** — Starknet 上的一个合约，用于验证每个 ZKThread 的状态变化。 ![](https://storage.googleapis.com/papyrus_images/0aa069c4e315e3e3acf7b7c12ba60b50ec52f3e5321c20da1d59d16cf2550d50.png) ZKThread 的运行逻辑如下： * 应用程序逻辑部署在线程的应用程序合约中，这些合约会在 dApp ZKThread 中产生交易和状态变化。 * ZKThread 中的交易在子区块中分批处理。 * 证明器创建子区块状态变化的 STARK 证明，并将其发送给 L2 排序器。 * ZKThread 验证器根据其持有的 dApp 规范记录验证状态变化证明。 * ZKThread 验证器接受或拒绝状态变更。如果接受，则更新规范记录。如果拒绝，则会取消 L2 上的 ZKThread 交易。 ZKThread 验证器的主要目标是证明由 ZKThread 发出的状态变更证明的有效性。它通过记录每个 dApp 的规范状态和操作系统版本，并将状态变更列表与规范状态进行对比来实现这一点。如果一切符合要求，ZKThread 交易将被接受，并更新规范状态。如果不符合要求，交易将被拒绝。 通过保持规范状态，ZKThreads 使得不同线程之间的互操作性变得更加容易，这与 L3 设计形成了鲜明对比，后者保持着完全不同的状态。 ZKThreads 的优胜之处 =============== 在传统操作系统和区块链领域中，进程和线程都是不同的组件。在 Starknet 中，L2 和 L3 应用链相当于进程，而 ZKThreads 则相当于操作系统中的线程。以下是 ZKThreads 与 L2 和 L3 应用链的区别： * **L2 和 L3 应用链**运行独立的进程，每个进程都有其独立的资源、设计和状态。尽管可以使用共享的数据可用性框架和其他机制来实现各种形式的互操作性，但这些方式远非理想之道。 * **ZKThreads** 是操作系统世界中区块链版本的线程。它们的进程在共享系统资源上运行，并通过 dApps 规范状态进行原生对接。ZKThreads 从一开始就是为了实现互操作性而设计的，引入了一种简单而优雅的设计，为零知识协处理实现了一种新的规范框架。 通过将 L2 和 L3 应用链以及 ZKThreads 整合到其可扩展性框架中，Starknet 创建了一个平衡性能、可组合性和互操作性的操作系统。ZKThreads 的部分优势包括： * **改善用户体验**：由于 ZKThreads 提供的互操作性，使用以 ZKThreads 构建的应用程序的用户无需更换网络和其他基础设施，就可以实现在不同应用程序之间的切换。 * **降低成本**：与 L3 相似，ZKThreads 通过在结算前增加另一层证明压缩，从而在 Starknet 实现额外的扩容，这意味着其成本将比公共 L2 更低。 * **线程不收费**：作为 ZKThread 运行的应用程序会定期批量更新基础层，这意味着用户无需为线程内的单笔交易支付费用。只有在基础层上结算时才需要支付费用。 ZKThreads：使用案例 ============== 正如 ERC-20 标准为我们如今看到的加密领域的各种用例铺平了道路一样，ZKThreads 也为那些需要更高层次互操作性的可证明应用程序打开了大门，这种互操作性在 L3 模式下是无法实现的。它们拓宽了 Starknet 可用的扩容解决方案的范围。请考虑以下几个方面： L2 DEX ------ ZKThreads 为 Starknet 上的 DEX 打开了大门。比如，由 StarkEx 提供支持的 [dYdX](https://dydx.exchange/)。如今，直接在 Starknet 上运行这样的平台尚不可行，因为用户将不得不为每一笔交易支付费用。通过使用 ZKThreads，用户则只需在提现时支付手续费。 基于会话的游戏 ------- ZKThreads 为扑克和国际象棋等基于会话的游戏提供了相同的解决方案。玩家无需为每一步行动支付费用，而只需在游戏结束且结果从线程提交到公共 Starknet 时支付一次费用。这就为更多类型的游戏打开了完全链上游戏的设计空间。 由零知识保障的中间件和共享流动性基础设施 -------------------- 借助 ZKThreads，预言机、桥以及其他形式的中间件无需从零开始构建验证器集合，也不需要依赖可能对底层链构成中心化风险的再质押形式。相反，它们可以直接作为一个 ZKThread 构建功能，并让在 ZKThread 框架中生成的零知识证明来保证安全性和互操作性。在流动性基础设施方面，这一点尤为重要，因为不同的应用程序可以共享其中的大部分功能。 以 [Uniswap Hooks](https://docs.uniswap.org/contracts/v4/overview) 为例，这是可用于定制池子、兑换、手续费和 LP 头寸在 Uniswap 上交互方式的插件。Uniswap Hooks 的模板代码与常规 Uniswap 相同，但协议的某些方面可以根据特定需求进行定制。在 ZKThread 的设计中，大部分程序都可以作为 ZKThread 托管，而存储的规范版本则可以提供可定制的 API，其中包含可供其他 ZKThread 和应用程序使用的钩子（hook）。 链上 AI、社交网络和其他通用实用工具 ------------------- 链上 AI 系统、社交图谱（跨平台跟踪用户接触点的数据库）以及其他可在各种应用程序中共享的库，都可以从上述庞大的通用数字资源库中受益。ZKThreads 提供了托管链上 AI 代理或模型所需的计算灵活性和资源。然后，该模型的规范状态可以在 ZKThread 管理器中进行镜像，以便在从游戏到社交网络再到生产力工具的各种应用程序中使用。 向可验证应用程序迈进 ========== 当然，上述潜在的新 dApp 列表并没有穷尽所有可以使用 ZKThreads 构建的潜在应用程序类型，但其提供了对 ZKThreads 所能实现的设计的洞察：一种融合了安全性、可组合性和互操作性的设计。正如 ERC-20 一样，ZKThreads 标准标志着区块链成熟的一个关键点。随着 ZKThreads 加入 Starknet 其他领先技术的套件，Starknet 将扩展其全面的零知识操作系统，旨在创建一个繁荣的可验证应用程序生态系统，在这个生态系统中，所有任意计算都可以被证明是正确的。长期以来，无需信任一直是区块链领域的承诺。有效性证明体现了对真实性的追求，是行业在计算历史中标志性的范式转变的最佳例证之一。因此，我们正朝着可验证应用程序的世界大步迈进。 --- *Originally published on [Starknet 中文](https://paragraph.com/@starknet-zh/zkthreads-dapp)*