Zhixiong Pan：
除了 EOF，另一个重要的协议层升级与扩容的实现是 EIP-4844，特别是与 Layer2 团队密切相关。年初，KZG 的 Ceremony 已经启动，而协议层的加入可能会需要一些时间。对于 Rollup、ZK Rollup 或者扩容这样的方向，大家认为 Layer2 团队可能需要多长时间来集成 EIP-4844？
关于集成 EIP-4844，大家认为可能会遇到哪些难点？此外，有没有估算过，使用 EIP-4844 对 GAS 或整体扩容会产生哪些影响？
Jolestar：
在我理解中，集成 EIP-4844 与原先的 Rollup 方案并没有改变太多。我们一直在寻求更高 TPS 和更低手续费的解决方案，但仅依赖 EIP-4844 无法解决这个问题。实际上，它只是增加了一种交易类型，即 Blob 类型，而整体的区块大小限制仍受限于基础层。如果我们希望实现理想的 Layer 2，具备几十万或接近十万量级的 TPS，第一层的交易仍无法直接放在一个区块上。
因此，我们现在的目标是实现一种不同方案可组合的模式，以便在成本更低、简单易用且具有更大通量的方案之间进行选择。
Dorothy Liu：
首先，EIP-4844 升级对于我们的 OP 来说相对容易集成，而对于 zkEVM 可能难度较高。有关此升级的专业解答，Zhang Ye 可以为大家提供。此外，我想分享一个名为 Monad 的协议，其创始人名叫 Keone，大家可以在 Twitter 上关注他。Keone 曾是 Jump 的开发人员，他是一个数学天才，擅长计算。他在 Twitter 上发布了关于 EIP-4844 协议上线后的预测，预测 Arbitrum 的 TPS 能够提高到大约 160，但这个数字是否显著，仁者见仁智者见智。他的测算方法是否有改进空间也值得商榷，但我们认为 EIP-4844 仅能在一定程度上提升性能，最终仍需依赖于 EIP-4844 与 Rollup 的结合，可能需要多个 Rollup 来提升性能。EIP-4844 本身无法解决太多问题。
对于我们来说，我们提供的服务名为「Rollup as a Service」，正如 Zhang Ye 所提到的，许多应用（如游戏和 DeFi 协议）需要高吞吐量，而对组合性要求不高时，它们可以运行在一个 Rollup 上。这些 Rollup 将共享一个去中心化的 Sequencer 网络，Prover 和 Validator 网络也将是去中心化的。这是我们当前提供的服务设想，我们将在下个月提供更多细节。因此，我们认为现有的 EIP-4844 或单独的 Rollup 方案无法解决所有问题，依赖大量 Rollup 为不同项目和应用场景提供服务才是关键。
Ye Zhang:
关于 EIP-4844，我们正在研究。EIP-4844 肯定会降低一部分数据成本。最近推特上有一个关于 Polygon 和 zkSync 数据成本的讨论。我们和 Polygon 现在都在使用交易的原始数据直接上链。Optimism 和 Arbitrum 会进行一定程度的压缩后再上链，而 zkSync 和 StarkWare 则使用更节省空间的 State Diff 模式。针对同一账户的高频操作，State Diff 可能会节省很多空间。有人分析了 zkSync 在使用 State Diff 后的数据，发现它确实可以节省一定的费用。但如果在有 EIP-4844 或分片后，数据成本进一步降低，我们还是更倾向于直接上链交易原始数据，因为这样可以让其他人看到你的数据后更快地执行交易，获得更强的保证。
我们希望在数据成本变低后，再加入一些压缩算法，可能会达到与 State Diff 相似的效果。但目前我们更倾向于使用交易原始数据。至于 EIP-4844 对我们的影响，它会影响两部分：一部分是我们的桥接（Bridge）方面，我们已经开始探索在 EIP-4844 下的新桥接设计，会有一些影响，需要写一个新的规范。另一部分是我们的电路（Circuit）里面，因为在新的格式下，我们无法直接访问之前的数据，只能访问一个小的承诺（Commitment），所以我们需要在电路里证明这个承诺的开放性。这对电路肯定是有开销的，但我们认为这是可行的。
实施 EIP-4844 会涉及到一个域的问题，因为数据是在另一个曲线上的，可能与原生数据格式不太一样。很早以前，Vitalik 提出了一个证明等价性的概念，但后来发现如果域不一样，还是会有一些问题。Dankrad 和 Vitalik 提出了一个复杂的方式来将承诺的开放性纳入电路。我们认为这个改动是确定性的，需要时间，但并不是特别复杂，是可行的。我们需要协调 Layer 1 什么时候实施这个改动，然后我们再进行相应的调整。在此之前，我们会继续专注于当前的系统。
Qi Zhou：
关于 EIP-4844，我们进行了大量研究。实际上，EIP-4844 的目的并非扩容，而更多是为了实现未来 Danksharding 所需的一整套概念，包括 Binary Large Object（blob）及其 Data Hash。在合约中可以访问 Data Hash，提前实现这些概念，以便在实现 Danksharding 时无需进行合约升级。EIP-4844 并不会比当前的以太坊数据上链方式带来显著改进，我们进行了初步估算，它们所带来的带宽基本上处于同一个量级。
然而，根据 Danksharding 的规格说明，吞吐量级约为 20 倍。因此，假设我们在 EIP-4844 上实现 100 TPS 的速度，使用 Danksharding 理论上可以达到 2000 TPS，甚至更高。以太坊社区，包括 Vitalik Buterin 和 Danksharding 团队，非常关注 EIP-4844 升级，因为一旦升级，接下来的以太坊重大升级将无需对整个合约系统进行升级。
我们的存储合约直接针对 EIP-4844 进行设计，从开发实现和存储证明等方面来看，实际上可能会更简单。使用 EIP-4844 提供的 Danksharding，系统实际上已经预先计算好了，对我们来说是非常友好的一种存储方式。
对于 ZK 和 Optimism 等技术可能存在挑战，尤其是关于如何传递数据。以太坊现在已经有一些工具，包括随机评估方式，能够将 Blob 数据重新传输到 CoreData 中。我们需要进行一些挑战，证明这些交易是否正确。
我们计划提供一些通用库，类似 OpenZeppelin 库，方便大家在 EIP-4844 上的 data blob 进行各种操作。这将在审计和 Gas 消耗方面带来安全和效率的优势。
总之，EIP-4844 对于以太坊整个数据层的操作具有创新性和巨大的潜力。对于对 EIP-4844 感兴趣的人，建议研究以太坊相关代码和参数设计，以便更好地了解如何使用这一技术。