使用 gasprice() 或 msg.value 传递信息

分析

这是一个非常规的、主要用于理论探讨或特定挑战（如 CTF 比赛）的技巧。它在实际生产环境中几乎不可行，且风险极高。

1. 核心思想：利用“免费”的全局变量

向智能合约函数传递参数需要消耗 Gas，因为交易的 calldata（调用数据）是按字节收费的（零字节 4 Gas，非零字节 16 Gas）然而，EVM 的每个交易上下文中都存在一些全局变量，例如 msg.value (交易附加的 ETH 数量) 和 tx.gasprice (交易设定的 Gas价格)。在合约内部读取这两个值的 Gas 成本极低（CALLVALUE 和 GASPRICE 操作码均为 2 Gas），并且与它们所承载的数值大小无关。

因此，理论上，我们可以通过在发起交易时精确设置这两个值，来向合约“免费”传递一个数字，从而省下 calldata 的 Gas。

2. 为什么这在生产环境中是不可行的？

尽管这个想法很巧妙，但它存在致命的缺陷，使其无法应用于真实场景。

• msg.value 的问题：成本高昂且画蛇添足

  • 真实成本： 使用 msg.value 传递信息意味着你必须在交易中附加真实的以太币。为了传递数字 10000，你就需要发送 10000wei。这点以太币的价值几乎总是远远超过你省下的那几个 Gas。

  • 功能限制： 这要求目标函数必须是 payable的，这会带来安全风险，并可能与合约的预期功能不符。你还需要处理接收到的以太币，增加了合约的复杂性。

• tx.gasprice 的问题：丧失交易控制权

  • 功能冲突： tx.gasprice 的唯一用途是决定你愿意为每个 Gas

单位支付多少费用，这直接影响你的交易被矿工打包的速度和成本。它是一个竞价工具，而不是数据通道。

• 无法控制： 你不能为了传递数字 10 就将 Gas 价格设为 10 Gwei。如果当时的市场 Gas 价格是 30 Gwei，你的交易将永远不会被处理。反之，如果市场价是 5Gwei，你将为交易支付过高的费用。你被迫使用市场价格，因此无法自由地用它来编码信息。

• EIP-1559： 在 EIP-1559 之后，tx.gasprice 被 maxFeePerGas 和 maxPriorityFeePerGas 取代，使得这个技巧变得更加复杂和不可靠。

测试

总结

这是一个展示 EVM 工作原理的绝佳思想实验，但绝不应在生产代码中使用。它所带来的经济风险和交易不确定性，远远超过了其微不足道的 Gas

节省。

对应源码

• Gas Optimization Master 配套代码

本文配套代码固定到提交 8960383；Gas 数据会随编译器、优化器参数和 EVM 版本变化。