Page 389 - 《软件学报》2025年第8期

3812 软件学报 2025 年第 36 卷第 8 期

知识证明算法, 同时它支持大规模的零知识证明计算, 在大规模场景下具有最好的生成证明的效率, 其中大规模指
的是证明函数的计算复杂度规模大. DeVirgo 是 Virgo 方案的分布式版本, 它可以将原本生成证明的电路拆成多个
部分可以并行进行零知识证明生成. 但直接使用 Virgo 的问题是最终证据的简洁性不够, 验证开销不小. Groth16
是另一种的零知识证明生成策略, 它的优势在于它最终生成的整体零知识证明 proof 大小是较小的, 因此它的验
证函数的计算量也较小. 因此 DeVirgo 用于并行化部分的证明, 而 Groth16 用于最终部分的证明生成. 目前 DeVirgo
和 Groth16 均已开源, 可以在文献 [16,17] 中找到相应的项目源码. 文献 [15] 指出, DeVirgo+Groth16 这个算法组合
被认为在可并行化的递归零知识证明中整体生成效率最高. 若不采用该方案, 选择文献 [9,13,18−22] 等方案均可
达成可用目标, 但整体效率均有所下降.

并行零知识验证算法
最终零知识验证算法
辅助零知识证明 proof1
原始并行验证函数 1
辅助零知识验证模块 1

并行零知识验证算法 辅助零知识验证模块 2
辅助零知识证明 proof2
证明输入 原始并行验证函数 2 整体零知识证明 proof

辅助零知识验证模块 3

并行零知识验证算法
辅助零知识证明 proof3 原始验证串行函数
原始并行验证函数 3

图 7 并行化零知识证明的验证方法

2.4 基于索引表数据压缩的交易存储方案

2.4.1 数据压缩策略概述
接收方 Rollup 在链上完成验证过程后, 需要执行接收方交易 TX receiver . 由于采用零知识证明的方案, 链上最终
只得到了零知识证明的 proof 和仅包含原始交易收据树根和接收方交易树根的明文输入数据, 而接收方 Rollup receiver
TX receiver 直接作为明文输入的原因是零知识证明
未获得接收方交易 TX receiver 的完整原始数据. 不将整批接收方交易
需要进入合约层执行计算并存储, 而通常 TX receiver 的交易存储量并不小, 直接在合约中存储会增加交易状态树的体
积, 给链上存储带来负担.
为应对这一挑战, 本节讨论的是如何优化原生链节点的存储消耗, 减少原生链节点的负载开销, 使得系统更有
效可靠. 本文提出了一套跨 Rollup 交易的存储方案. 对于交易的链上存储, 使用特殊的 EIP-4844 协议的 blob
(binary large object) 方式来存储待传输的接收方交易 TX receiver , 可以将无计算的二进制文件交由特殊的存储节点存
储, 避免所有全节点的存储开销, 可详见第 1.3 节的描述. 对于实际要存储的数据, 引入了新的一种数据压缩策略
来优化存储, 包括两个主要部分, 分别是交易数据结构压缩和索引表压缩.
(1) 交易数据结构压缩: 为了解决交易存储量大的问题, 本文采用了一种交易存储压缩的数据结构, 该技术精
简了以太坊交易信息, 用最简数据结构来代替完整的交易结构. 具体而言, 本文仅保存交易信息中的必要字段, 只
包含交易双方地址、交易金额及合约数据, 而不保存不必要的信息, 如交易备注、交易 Gaslimit 费用等. 同时对于
批量交易, 合并相同的字段减少平均单笔交易的开销.
(2) 索引表构建: 面对交易的部分字段高频出现的特点, 本文在链上构建了一个索引表, 将较长字段及其对应