ZKBase 是基于 ZK Stack 和多 GPU 证明器的高性能 ZK-Rollup。该解决方案增强了交易处理能力，并提供了经济高效的网络体验。其关键优势在于采用了零知识证明（ZKP）技术，允许快速验证和确认链下交易，同时保持交易隐私和数据完整性。由于所有有效性证明都在以太坊上进行验证，因此用户可以享受与 L1 相同的安全保障。ZKBase 的运行方式与以太坊类似，但吞吐量更高，费用更低。智能合约以 Solidity/Vyper 编写，可以使用与其他兼容 EVM 的链相同的客户端进行调用。本文将介绍 ZKBase 的核心工程和技术实现。 1. ZKBase的关键组件 ：这些组件使用 RocksDB 来维护 L2 存储树的本地副本。数据库与最新的状态根哈希保持同步，持续反映当前系统状态。 Tree 和 TreeBackup ：执行交易并将封闭的块安全地存储在本地 RocksDB 数据库中，确保数据完整性和持续的状态更新。 StateKeeper/VM ：这些智能合约部署在以太坊主网上，用于验证从链下提交的零知识证明 (ZKP)。验证成功后，这些合约将更新以太坊网络上的账户状态。 智能合约 ：一种 ZK-Rollup 技术，通过零知识证明确保安全高效的交易验证。当一批交易在以太坊主网外发生时，ZK 聚合系统会将多笔交易压缩为由 Prover 计算的单个“有效性证明”，以证明该批次的正确性。然后，该证明被提交到以太坊网络，从而能够快速安全地确认链下发生的大量交易。 GPU Prover ：ZKBase 提供了 ZKBase 与以太坊主网之间资产安全转移的桥接机制，保证了两个平台之间的互操作性和资产流动性 桥接 2. ZKBase 工作流程 用户可以通过应用程序编程接口 (API) 或部署在 L1 上的合约发起 L2 请求。提交后，这些请求将进入内存池，等待执行。值得注意的是，源自 L1 的交易（例如存款）存储在专用的 L1 优先级队列中，以确保及时处理它们。 mempool 存储结构是 btreeset（用 btree 实现的集合），索引结构如下： 这里 fee_data 不参与实际分数计算，但有助于过滤掉不符合费用要求的交易。分数按时间戳排序，如果时间戳相同，则按地址排序。 内存池中的交易由状态守护者内的内存池提取器组件管理。除过期交易外，标准交易将按照 B 树遍历定义的顺序从内存池中提取并记录在数据库中。然后由状态守护者/VM 处理、执行并用于更新状态树。 区块布局图展示了区块内交易的组织方式，以及 L1 批次内 L2 区块的排列方式。 为了启动每个 L1 批次，操作员需要输入关键详细信息：批次的时间戳、其在序列中的位置以及前一个批次的哈希值。 Merkle 树根哈希在此过程中充当基础根哈希，以确保批次的有效性和交易的真实性。同时，状态守护者有权决定何时完成特定的 L2 块或 L1 批次，从而确定其状态。此决定由一组由 conditional_sealer 模块管理的预定义标准控制。这些标准包括交易计数、大小限制和 gas 使用阈值等参数。处理交易后，状态守护者会检查满足哪些密封条件。 conditional_sealer 维护一个 SealCriteria 注册表，其中包括： 交易数量限制， L2 gas 限制， 发布数据量的上限以及其他规定。 决策场景有四种：NoSeal、IncludeAndSeal、ExcludeAndSeal 和 Unexecutable。前两种情况的流程相同，执行后状态在 State Keeper 中更新。ExcludeAndSeal 处理超出预定义批量限制的交易，方法是回滚交易执行并将其放回队列以包含在下一个 L2 块中。如果发生 Unexecutable 情况，则交易无法执行并将被拒绝。 在每个批次结束时，引导加载程序都会生成一个占位符 L2 块以完成交易并为下一个周期做准备。尽管该块大部分是空的，但它对于内部操作至关重要，并包含一个转移事件日志，用于记录引导加载程序和操作员之间的费用流动。为了确保时间准确性，批次和最后一个子块的时间戳会与预期的 L1 时间框架进行交叉检查，以增强系统对时间相关问题的弹性。 一旦批次最终确定，证明者就会生成加密证明来验证区块的执行情况。在 ZKBase 中，证明者的责任是证明 ZKBase 以太坊虚拟机 (EVM) 的准确执行。然后，此证明由以太坊网络上的智能合约进行验证。生成证明后，证明者将其打包成 L1 交易并将其发送给 ETH_Sender。ETH_Sender 将交易转发到部署在以太坊主网上的 ZKBase 合约进行进一步处理。 以太坊主网验证证明的正确性，并在验证成功后相应地更新状态。 在整个过程中，EthWatcher 持续监控特定的 L1 事件，例如存款和系统升级，以确保与以太坊主网同步。 3. 多 GPU 证明器架构 该架构利用 Postgres 数据库共享数据，实现跨多个 GPU 证明器的并行计算，以提高证明生成效率。关键组件包括： ：提供第 2 层服务的服务器。 运营商 ：连接操作员与验证子系统的通信模块。 验证器网关 ：生成证明计算任务并存储中间产物。 见证生成器 ：将所有计算任务聚合为适合 GPU 计算的向量格式并将其发送给证明者。 向量生成器 执行实际的计算和证明的验证。 证明者： 将最终证明压缩为SNARK形式。 压缩器： 证明生成工作流程 ：操作员收集交易并生成新的批次。 批次生成 ：证明者网关从操作员处检索新批次并开始准备生成零知识证明。 批次接收 ：Prover Gateway 将批次信息插入 Postgres 数据库。后续数据处理直接与数据库交互，从相应的输入表中检索数据，并将处理后的数据放入相关的输出表中。 数据库插入 ：此初始阶段发生在用户发起交易时，生成见证。见证基于网络共识规则证明交易的有效性，但不透露任何交易细节。新的交易见证被分批收集和处理。每批经历以下流程： 见证生成 基本电路见证生成器 叶子聚合见证生成器 节点聚合 调度器 ：向量生成器整合电路以产生见证向量，从而优化 GPU 计算能力的使用。 向量生成 ：证明者利用 GPU 计算零知识证明，验证证明计算的正确性。 证明计算 ：压缩机模块压缩证明以减少数据大小，并将其转换为 SNARK 形式。 压缩 4。结论 ZKBase基于ZK Stack和Multi-GPU Prover实现高性能的Layer 2扩展性，但以太坊扩展方案ZK-Rollup仍面临诸多技术挑战，未来ZKBase将继续研究和探索去中心化排序和去中心化ZK算力网络的实现。
