智能合约交易事件参数顺序异常：如何确认参数位置？

问题背景 #

查看某以太坊交易的事件日志，事件函数定义如下：

BurnConfirmed (index_topic_1 uint256 nonce, index_topic_2 address requester, uint256 amount, string btcDepositAddress, string btcTxid, uint256 timestamp, bytes32 inputRequestHash)

手动截取事件数据最后128位（data[-128:]）并转换为文本后，得到的是btcTxid而非定义中最后一个参数inputRequestHash，需要确保参数解码位置正确。

核心原因 #

以太坊事件参数遵循ABI编码规范，动态类型（如string）不会直接存储在参数顺序对应的位置，而是先存储指向实际数据的偏移量，实际内容放在数据段的尾部。手动按固定位置截取会破坏这种编码逻辑，导致取到错误的参数值。

正确解决方案：使用ABI规范解码 #

不要手动截取数据，直接用Web3.py的ABI解码工具，按事件定义的ABI解析日志数据，步骤如下：

1. 定义事件ABI
   根据事件函数定义，编写对应的ABI片段：

burn_confirmed_abi = {
    "anonymous": False,
    "inputs": [
        {"indexed": True, "name": "nonce", "type": "uint256"},
        {"indexed": True, "name": "requester", "type": "address"},
        {"indexed": False, "name": "amount", "type": "uint256"},
        {"indexed": False, "name": "btcDepositAddress", "type": "string"},
        {"indexed": False, "name": "btcTxid", "type": "string"},
        {"indexed": False, "name": "timestamp", "type": "uint256"},
        {"indexed": False, "name": "inputRequestHash", "type": "bytes32"}
    ],
    "name": "BurnConfirmed",
    "type": "event"
}

2. 解码日志数据
   获取日志的topics和data（索引参数会放在topics里，非索引参数在data里），然后调用w3.eth.abi.decode_log解码：

# 假设你已经获取到日志的topics和data
topics = ["0x...", "0x...", "0x..."]  # 对应indexed的nonce、requester，以及事件签名
data = "0x000000000000000000000000000000000000000000000000000000746a52880000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000638a1cf7d71eaa8219d43a9ae3659cd0ce3c6d30e4127b810596c00d7c98f6cf717f7177000000000000000000000000000000000000000000000000000000000000002a6263317167656e3833346c73783667397074766c673834333637643865376879663332647630396a617500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004064363634386331373036346561643238633261303230343762656139313732623962346339303333643239343535366533353637303965396137313964363363"

# 解码日志
decoded_log = w3.eth.abi.decode_log(
    burn_confirmed_abi["inputs"],
    data,
    topics[1:]  # topics[0]是事件签名，所以从第1个开始取索引参数
)

# 输出正确的参数值
print(f"inputRequestHash: {decoded_log['inputRequestHash'].hex()}")
print(f"btcTxid: {decoded_log['btcTxid']}")

3. 关键说明

• 索引参数（indexed为True）会被放在topics数组中，topics[0]是事件的签名哈希，后续topics对应索引的参数。
• 非索引参数全部编码在data字段中，ABI解码会自动处理动态类型的偏移量，确保每个参数都对应到正确的位置。

为什么手动截取会出错 #

你的代码中data[-128:]取到的是最后两个64字节的内容，而btcTxid作为string类型，其实际内容存储在数据的尾部，inputRequestHash作为固定长度的bytes32类型，会在动态类型之前的位置（根据ABI编码顺序，固定类型参数在前，动态类型参数的偏移量在前，内容在后）。手动截取完全忽略了ABI的编码规则，所以得到错误的结果。

内容的提问来源于stack exchange，提问作者OcMaRUS