在以太坊区块链的世界里,交易不仅仅是发送代币那么简单，它们更像是向去中心化应用（DApps）发送的指令，当我们发送一笔交易来调用一个智能合约中的函数时，我们如何知道函数是否执行成功？它又返回了什么结果？答案就藏在“回执”（Receipt）中，而函数返回值的处理方式，随着以太坊的不断升级，尤其是EIP（以太坊改进提案）的引入，也经历了重要的演进，本文将深入探讨以太坊回执中的函数返回值，并重点介绍与之密切相关的EIP，特别是EIP-1159及其影响。

以太坊回承（Transaction Receipt）：交易的“回执单”

我们需要明确什么是“回执”，当一笔交易被矿工（或验证者）打包进区块并执行后，以太坊节点会生成一个回执，回承就像是交易执行的“回执单”或“收据，它记录了这笔交易的执行结果和相关元数据，一个典型的以太坊回承包含以下关键信息：

  • transactionHash：交易的唯一标识符。
  • status：交易执行状态，1表示成功，0表示失败。
  • contractAddress：如果交易是合约创建，则这里是新合约的地址；否则为null。
  • gasUsed：交易执行消耗的 gas 数量。
  • logs：交易触发的事件（Event）列表。
  • **logsBloom：用于高效过滤日志的布隆过滤器。
  • blockNumber：交易所在区块号。
  • blockHash：交易所在区块的哈希。
  • from / to：交易发起方和接收方地址。
  • cumulativeGasUsed：到当前交易为止，区块中所有交易累计消耗的 gas。

函数返回值：在回承中的“隐身”与“显形”

在早期的以太坊（尤其是EIP-1159之前），智能合约函数的直接返回值并不会自动包含在回承中，这意味着，如果你调用一个函数并期望它返回一个复杂的数据结构（比如一个字符串或一个数字数组），仅仅查询回承是无法直接获取到这个返回值的。

函数返回值去哪儿了？

  1. 状态变更（State Changes）：函数执行最核心的影响是改变了区块链的状态（更新了合约的某个状态变量），这些状态变更会永久记录在区块链上，你可以通过后续调用合约的查询函数（通常以view或pure修饰，不消耗gas，不改变状态）来获取这些变更后的值，这间接反映了函数执行的部分结果。
  2. 事件（Events）：这是开发者主动向“外部”传递函数执行结果的重要方式，函数内部可以emit一个事件，并将需要返回的数据作为事件的参数，这些事件会被记录在回承的logs字段中，外部应用可以通过监听这些事件来获取函数的返回信息，这是最常用、最推荐的方式在回承中传递“返回值”。
  3. 直接返回值的限制：由于以太坊的设计哲学，交易执行完成后，节点向交易发送者（或通过JSON-RPC接口查询者）返回一个“收据”（receipt），这个收据本身并不包含函数调用的原始返回值，如果发送者需要这个返回值，它必须在发送交易时同步等待，或者通过其他机制（如事件）异步获取。

EIP-1159：不是直接改变函数返回值，但深刻影响交互

EIP-1559（“伦敦硬分叉”的核心改进）主要改变了以太坊的Gas费用机制，引入了基础费用（base fee）和优先费用（priority fee）。它并不直接改变函数返回值在回承中的存储方式，它对交易执行和回承的获取方式有间接但重要的影响：

  • 更可预测的Gas费用：EIP-1559使得交易费用更加可预测，减少了网络拥堵时的极端Gas价格波动，使得调用函数获取返回值（无论是通过同步等待还是事件监听）的成本更可控。
  • 交易 inclusion 的确定性：由于基础费用的燃烧机制，矿工（验证者）更倾向于打包优先费用合理的交易，这提高了交易被及时打包的概率，从而使得函数执行和回承的生成更及时。

与函数返回值更直接相关的EIP

虽然EIP-1159不直接处理函数返回值，但其他EIP对此有更直接的影响：

  1. EIP-2930：访问列表（Access Lists）

    • 目的：优化交易处理，减少访问存储时的 gas 消耗。
    • 与返回值的关系：间接相关，通过减少 gas 消耗，使得获取复杂返回值（需要多次存储访问）的成本降低，效率提高。

  2. EIP-712：类型化数据签名（Typed Data Signing）

    • 目的：允许对结构化数据进行签名和验证，提高 dApp 中用户交互的安全性和用户体验。
    • 与返回值的关系：虽然不直接存储返回值，但 EIP-712 常用于签名函数调用参数，或者在函数返回特定数据结构时，让用户能够验证数据的来源和完整性，一个函数返回一个复杂的报价对象，可以使用 EIP-712 对其进行签名，接收方可以验证签名是否有效。

  3. 未来的EIP与展望：函数返回值的“显形”

    • 以太坊社区一直在探索如何更高效、更直接地处理函数返回值，有提案探讨是否可以通过某种方式将函数的返回值（尤其是小型、高频使用的）更便捷地包含在回承中，或者通过改进的 RPC 接口让开发者更容易获取到这些返回值。
    • 这需要权衡区块链的存储成本、数据可用性以及安全性，通过事件传递返回值仍然是主流且被广泛接受的方式，因为它提供了灵活性和可扩展性。

实践中的函数返回值获取

在实际开发中,开发者通常通过以下方式获取函数返回值：

  • 同步调用（适用于view/pure函数）：使用 Web3.js、ethers.js 等库，可以直接调用view或pure类型的函数，这些函数不改变状态，无需发送交易，会同步返回结果。const result = await contract.myFunction();。
  • 异步调用（修改状态的函数） 事件监听：
    1. 发送交易调用函数。
    2. 等待交易被打包,获取回承，确认status为1（成功）。
    3. 在回承的logs中查找特定的事件，解析事件参数获取返回值。
    4. 或者,在发送交易时监听该事件，一旦事件触发即可获取返回值，无需等待回承确认（但最终仍需回执确认交易成功）。
  • 查询合约状态：如果函数的返回值影响的是合约的某个状态变量，那么可以通过后续调用该状态变量对应的view函数来获取。