Viem项目中OP-Stack的L1 Gas估算问题分析与解决方案

问题背景

在Viem项目的OP-Stack实现中，estimateL1Gas函数的设计目的是计算与L2交易相关的L1成本。然而，当前实现存在一个关键问题：它不必要地调用了eth_estimateGas方法，导致了一系列衍生问题。

问题分析

当前实现的问题

1. 不必要的Gas估算：estimateL1Gas函数本应仅通过GasOracle合约计算L1成本，但实际上调用了prepareTransactionRequest，进而触发了eth_estimateGas调用。

2. 账户依赖性问题：由于进行Gas估算，函数需要有效的账户参数。如果提供的账户没有足够资金，就会导致错误。

3. 功能混淆：L1成本估算理论上只需要to和data参数，不应该涉及L2 Gas估算。

技术细节

问题的核心在于prepareTransactionRequest的调用逻辑。当gas参数未定义时，它会自动触发eth_estimateGas。而L1成本估算实际上只需要交易的基本信息（目标地址和调用数据），不需要完整的交易准备过程。

解决方案

临时解决方案

一个临时的解决方法是显式设置request.gas为null（注意：null !== undefined），这样可以避免触发Gas估算。

理想解决方案

更彻底的解决方案应该是重构estimateL1Gas和estimateL1Fee的实现：

1. 移除不必要的交易准备：L1成本估算不需要完整的交易准备过程。

2. 简化参数要求：只需要最基本的交易信息（目标地址和调用数据）。

3. 分离关注点：明确区分L1成本估算和L2 Gas估算的逻辑。

影响范围

这个问题不仅影响estimateL1Gas，也影响了相关的estimateL1Fee功能。任何依赖这些函数进行L1成本估算的应用都可能遇到相同的问题。

最佳实践建议

对于开发者来说，在使用这些函数时应注意：

1. 如果只是需要L1成本估算，确保使用正确的函数和参数。

2. 避免在不必要的情况下提供账户参数。

3. 关注Viem项目的更新，及时应用修复后的版本。

总结

这个问题揭示了在Layer2解决方案实现中，L1和L2操作边界划分的重要性。正确的实现应该清晰地分离不同层的责任，避免不必要的跨层操作。对于Viem项目来说，修复这个问题将提高OP-Stack集成的健壮性和可用性。