本文内容
Web3 Gas 成本复盘：如何比较 L1、L2 与 Solana
Gas 是工作负载的计量单位，不是长期不变的美元价格。在 Web3 产品中，用户或赞助者支付的成本取决于程序、交易数据、fee market、原生代币价格、赞助方式和当前网络规则。固定美元表格和通用 L1/L2 倍数很快会过时。
本文用可复现的决策方法取代汇总百分比和统一链建议：生产形态的交易、当前 RPC 估算、官方费用公式，以及对结算、最终性、数据可用性、桥、升级、托管和运营的明确假设。
正在构建 Web3 产品？
预约免费咨询成本在哪里产生？
在 Ethereum 上，gas 衡量计算工作。费用为实际 gas 乘以 base fee 与 priority fee；耗尽 gas 可能回滚状态，但仍消耗已用 gas。简单 ETH 转账使用 21,000 gas，合约调用则随实现和状态变化。参见官方 Ethereum gas 文档。
- 部署与升级。创建合约会存储 bytecode 并初始化；proxy、迁移和验证另有成本。
- 用户写入。转账、铸造、swap、claim、approval、账户抽象验证和状态变更每次执行都消耗资源。
- 失败或替换的交易。已包含的失败仍可收费；重试、nonce、slippage 与赞助策略都应建模。
- 数据与结算。Rollup 通常同时收取子链执行和父链数据或结算资源费用。
- 链下服务。RPC、索引、relayer、paymaster、预言机、keeper、签名、监控和支持不是 gas，但属于 TCO。
只读 RPC 不创建链上交易，但提供商可以收取 API 费用。合约执行时无法免费调用 RPC；链上读取与存储访问属于 gas。
为什么静态费用表会误导？
美元估算组合了多个变化输入。至少记录交易或 UserOperation、gas 或 compute unit、calldata 或压缩大小、base fee、priority fee、父链或 blob fee、operator fee、赞助开销、代币价格来源、区块或 slot、时间戳和成功状态，并在不同需求水平重复测试。
| 网络 | 要测量的费用模型 | 重要边界 |
|---|---|---|
| Ethereum | 实际 gas 乘 base 与 priority fee | 需求和合约路径改变费用，USD 还随 ETH 变化 |
| Base | L2 执行加估算 L1 security fee | L1 数据成本随 Ethereum 与交易数据变化 |
| OP Mainnet | 执行、L1 数据和适用 operator fee | 当前升级与链参数影响公式 |
| Arbitrum One | 子链执行资源加父链 poster 费用 | 压缩大小和父链定价影响 poster fee |
| Polygon PoS | 以当前 gas token 支付的 EIP-1559 估算 | 它是 EVM sidechain，不是 Ethereum rollup |
| Solana | 按签名 base fee 加可选 priority fee | 账户、compute limit、价格、签名和账户资金影响总成本 |
Base 在网络费用文档中说明 L2 execution fee 与 L1 security fee。OP Mainnet 在交易费用指南中说明执行、L1 数据和随升级适用的 operator fee。
Arbitrum 记录了子链资源和依据压缩大小与父链定价计算的 poster 组件。参见 Arbitrum gas and fees。因此，面向所有 EVM L2 交易的通用倍数并不是长期有效的说法。
如何比较 Polygon PoS 与 Solana？
Polygon 文档把 Polygon PoS 描述为定期向 Ethereum 提交 checkpoint 的 EVM-compatible sidechain。其文档说明 base 与 priority fee，gas station 提供当前估算。使用官方 Polygon PoS EIP-1559 指南并记录当前 gas token 与参数。不要把 sidechain 与 rollup 等同。
Solana 使用不同模型，包括按签名 base fee 和可选 priority fee。优先费取决于请求的 CU 上限，而不是实际用量。文档目前列出每个签名 5,000 lamports，但预算前应重新核对该网络参数。参见官方 Solana 费用结构。
较低的抽样费用或较短区块时间不能证明应用延迟、最终性、可用性、抗审查性、桥安全或运营成本。应在实际 commitment 与失败场景下测试。
Wavect 项目历史能证明什么？
Wavect 在 EVM 与 Solana 环境交付过产品，但这些项目不是标准化 benchmark。合约、频率、价格、赞助、市场时期和客户要求都不同。
- Scramble Pay：多链支付背景。
- Quivr：Solana 消费产品背景。
- 账户抽象：赞助与智能账户流程。
- Lightbridge：跨链消息需求。
- MetaMask Snap：钱包扩展集成。
这些只是项目背景，不能证明某个网络最便宜或最适合下个产品。
"选链是产品与风险决策。测量真实工作负载，再比较每条路线的结算、最终性、数据、托管、升级与运营假设。"
创始人应如何比较网络？
- 定义用户与结算结果。明确谁提交、签名、赞助、接收、争议或恢复，以及用户与资产在哪里。
- 创建生产形态 fixtures。涵盖常见、最坏、失败、批量、赞助、建账户、桥、DeFi、NFT 和升级路径。
- 先估算原生单位。使用 RPC 模拟与官方公式，把 gas、bytes、CU、签名、存储与 fiat 分开。
- 跨时间采样。记录区块或 slot、时间、费用参数、价格来源和百分位策略。
- 建模生命周期 TCO。加入 RPC、索引、relayer、赞助、桥、监控、事件、升级、审计、流动性和支持。
- 审查安全与控制。比较最终性、数据可用性、sequencing、proof 或 checkpoint、admin key、暂停、升级、桥和退出。
- 有意识地选择主路线。多链会增加合约、集成、流动性、监控与失败模式。
如果考虑专用 blockspace，请比较原生与 based rollup 架构。排序、验证、数据、互操作、治理和运营是不同决策。
注明日期的 benchmark 应包含什么？
发布审查日期、网络与 chain ID、交易 hash 或可执行 fixture、合约与状态、RPC 方法、gas 或 compute、L1 数据计算、费用参数、原生与 fiat 价格来源、确认规则，以及是否包含建账户、桥、失败、赞助和服务成本。
不要把钱包估算称为保证，也不要把一次 transfer 外推到 mint、DeFi 或 UserOperation。赞助流程应同时展示用户看到的价格和赞助者的实际网络与服务成本。
Ethereum mainnet 会是正确的首发选择吗？
没有通用答案。当用户、资产、协议、结算或治理要求它时，mainnet 可能合适；其他工作负载可能更适合 L2、sidechain 或 Solana。低费用不能弥补用户、流动性、集成、安全要求或恢复选项的缺失，高费用也不能单独证明应用安全。
最终思考
只有能改进下一次测量时，gas 成本复盘才有价值。固定 USD 表格、无依据的项目百分比和通用选链默认值会掩盖实际变量。Ethereum、Base、OP Mainnet、Arbitrum One、Polygon PoS 与 Solana 使用不同且变化的费用与结算模型。
从产品结果出发，构建 fixture，测量 智能合约周围的原生单位和每项费用，跨时间采样，并加入链下与生命周期成本。再比较安全、最终性、数据、治理、桥、升级和运营假设。保留注明日期的证据，以便工作负载或网络变化后重新评估。