Morph：EIP-4844 zkEVM与聚合证明集成解决方案

背景

EIP-4844 提出了一种称为「Blob-carrying 交易」的新交易类型，这种交易包含大量无法通过 EVM 执行访问的数据，但这些交易的承诺可以被访问。交易类型旨在与分片方案中使用的格式完全兼容。

一个 Blob 是一个包含 4096 个有限域元素的向量（该有限域为 BLS12-381 标量域）。在数学上，4096 个有限域元素可以插值出一个阶数为 4095 的多项式 p(x)，该多项式在 wi处的取值恰为第 i 个有限域元素。

而 Blob 承诺可以由 KZG commitment 计算而来，且通过相对应的验证方法验证。

EIP-4844 中介绍的部分常量：

EIP-4844 在 Rollup 过程中有着至关重要的作用。与将 Rollup 数据放入交易 calldata 中不同，rollup 希望 submitter 将数据放入 blob 中。这一方案既保证了数据可用性，又能够减少因为使用大量的 calldata 而产生的链上花销。Rollup 需要保证数据的可用性，在足够长的时间内确保诚实的操作者可以构建状态验证，但是该数据不需要一直存在在链上。ZK rollup 将为其交易或状态提供两种承诺：Blob 承诺以及 zk 证明。

EIP-4844 KZG Commitment 的等价证明

在现阶段零知识证明电路实现中，因为暂不支持以 BLS12-381 椭圆曲线为基础的二元线性对验证等复杂非原生有限域操作，所以通过对于多项式挑战点取值一致性与承诺有限性的等价性将对于 Blob 承诺的验证转换为对于任意挑战点取值的一致性验证。

EIP-4844 的一致性证明包含三个部分：

交易原文与 Blob 的一致性验证

首先设计电路证明 Blob 中的交易原文与 Blob 的有限域的对应关系，该电路的输入为交易原文以及 4096 个有限域元素, 约束编码的计算逻辑，由交易原文编码到 Blob 的编码采用如下方案：

• 将输入数据中的 31bytes 编码成 32bytes，为一个 bls12-381 标量域元素，且编码后的数据不超过标量域模数范围。为了支持后续 blob 分片验证的方式，我们将 Batch 中的输入数据（交易原文信息）按照 chunk 划分。
• 对于每一个 chunk 的 blob 编码，我们将该 chunk 的输入数据长度存入第一个 31bytes 中的前 4bytes，并且该 chunk 输入数据分片的前 27bytes 数据编码至剩余的 27bytes 中，构成了 chunk 分片 blob 中的第一个有限域元素（32bytes，第一个 bytes 为 0，第二至第四个 bytes 表示该 chunk 输入数据长度，剩余 27 个 bytes 保存数据的前 27bytes 数据）。
• 将该 chunk 后续输入数据按 31bytes 划分存入 32bytes 中, 在该 chunk 最后数据不足 31bytes 时，末位补零。

该编码方式将 Batch length 切分成多个 Chunk length 存入每个 chunk 分片中的 blob 元素中，更利于后续的可聚合方案设计。

Blob 多项式求值验证

该电路用于验证 Blob 差值得到的多项式 p(x) 在任意一点（Challenge Point）x 上的取值为 y。通过这种方法将无法直接验证 blob commitment 的 EIP-4844 Blob 验证转变对于挑战点 x，多项式取值 y，以及多项式承诺 c 的验证。该电路的输入为 4096 个有限域元素，以及挑战点 x，输出为多项式计算结果 y。

Blob 多项式求值逻辑主要采用 Barycentric 求值公式，对于有 4096 个有限域元素的 Blob：

求值公式为：

Blob 承诺与取值一致性验证

在这一步之前，对于 Blob 和其承诺的一致性校验已经转换成 challenge pointx, 函数值 y 和 Blob 承诺的一致性校验, 在 EIP-4844 的支持下，智能合约可以拿到 Blob 的 commitment，这一部分的验证可以直接由链上合约完成，下面我们讨论上一步中电路求值的聚合优化。

Blob 可聚合验证方案

在 Blob 中每 32bytes 数据可以用一个 BLS12-381 标量域表示，但是原始交易数据中每一笔交易原文数据的长度是不固定的，因此可能遇到下列问题：

• 无法保证对于一个 chunk 中的交易原文是 32bytes 的整数倍, 所以一个 chunk 中的交易数据不一定恰好编码为整数个有限域元素
• 交易数据在编码后可能分布在两个 Blob 中
• 一个 Batch 或者 chunk 数据编码后可能不足 4096 个有限域元素，Blob 空间利用率不高

为了解决第一个问题，我们在一个 Chunk（对应的交易数据）进行补 0，使得一个 Chunk 所能容纳的交易个数所编码的有限域个数为整数个；对于第二个问题，我们要求一个交易不会跨过两个 Blob 存储，同时对于多个 Blob 采用 KZG commitment 的多点打开的方式进行优化。

对于第三个问题，我们提出新的聚合方案。首先我们会将原本前五位中的四位存放 batch 的长度信息修改为在每一个分片中的前五位中的四位存放分片 chunk 的长度信息，后续编码方式一致，同时 Chunk proof 中除编码一致性检查外，输入该 chunk 中交易数据所编码的有限域元素索引值（chunk 中的第一笔交易以及最后一笔交易所在 Blob 中的元素索引值）。

我们的方案有以下优势：

• 兼容性：EIP-4844 使用 Blob-data，我们方案具体考虑实现了交易原文数据到 Blob-data 的编码过程，与现有的 ZKevm 电路兼容。
• 实用性：以太坊预编译合约仅支持 BN254，使用 BLS12-381 去验证 KZG commitment 将导致大量非原始曲线的标量域计算（如配对操作），导致消耗大量 gas；我们使用 Barycentric 公式大幅降低了错域计算的数量，保证了实际计算量是可行的。
• 聚合性：聚合证明可以降低证明的数量并减少验证的次数，降低链上 gas 消耗。我们的方案从 chunk-level 的角度提高了聚合的程度，结合 EIP-4844 可以更好的降低 gas 消耗。

结论

Layer-2 方案在以太坊的扩容路线图中扮演着重要角色，然而也存在着安全性的争议和性能上的不足。ZK-rollup 使用坚实的数学理论，有着很高的安全性保证，尽管这伴随着生成证明和验证证明的消耗。通过更好的算法和硬件，生成证明的代价可以有效降低；通过优化链上计算和存储的逻辑，后者也可以得到优化。

EIP-4844 作为 rollup 方案的催化剂，可以给链上数据存储的 gas 消耗带来极大优化，也带来了应用中实际问题的挑战。本文提出了一种在 EIP-4844 提案下实用且高效的电路设计方案，有效降低 gas 消耗并兼容解决了 EIP4844 在应用时的一些问题。Morph 团队始终追求创造更低成本和更高安全的交易生态，本着这一愿景，不断探索新技术并希望为社区生态贡献更多。