![大咖网](https://www.18btc.com/wp-content/uploads/2023/05/logo-2.png)
什么是以太坊交易回执(Receipt)?
交易回执(Receipt)是指在以太坊网络上发起的交易完成后的确认信息,包含了交易的执行结果、状态变化以及其他相关的信息,可以被用来验证交易的有效性和状态。
什么是以太坊交易回执
不同于比特币,以太坊作为智能合约平台。每一笔交易作为消息在以太坊虚拟机中执行时,均会获得一个交易回执信息。形同在银行转账后,可以获得关于这笔转账的交易电子回单。
同样,在以太坊中一份交易回执记录了关于此笔交易的处理结果信息:
![以太坊交易回执数据结构](https://www.18btc.com/wp-content/uploads/2023/10/1007-81-2。.jpg)
以太坊交易回执数据结构
以太坊交易回执内容
回执信息分为三部分:共识信息、交易信息、区块信息。
![以太坊交易回执内容](https://www.18btc.com/wp-content/uploads/2023/10/1007-81-3.jpg)
以太坊交易回执内容
交易回执共识信息
共识意味在在校验区块合法性时,这部分信息也参与校验。这些信息参与校验的原因是确保交易必须在区块中的固定顺序中执行,且记录了交易执行后的状态信息。这样可强化交易顺序。
Status
成功与否,1表示成功,0表示失败。注意在高度1035301前,并非1或0,而是 StateRoot,表示此交易执行完毕后的以太坊状态。
![交易回执共识信息](https://www.18btc.com/wp-content/uploads/2023/10/1007-81-4.png)
交易回执共识信息
CumulativeGasUsed
区块中已执行的交易累计消耗的Gas,包含当前交易。
Logs
当前交易执行所产生的智能合约事件列表。
Bloom
是从 Logs 中提取的事件布隆过滤器,用于快速检测某主题的事件是否存在于Logs中。
这些信息是如何参与共识校验的呢?实际上参与校验的仅仅是回执哈希,而回执哈希计算只包含这些信息。
首先,在校验时获取整个区块回执信息的默克尔树的根哈希值。再判断此哈希值是否同区块头定义内容相同。
![共识校验](https://www.18btc.com/wp-content/uploads/2023/10/1007-81-5.png)
共识校验
而函数types.DeriveSha中生成根哈希值,是将列表元素(这里是交易回执)的RLP编码信息构成默克树,最终获得列表的哈希值。
![列表的哈希值](https://www.18btc.com/wp-content/uploads/2023/10/1007-81-6.png)
列表的哈希值
交易回执实现了 RLP 编码接口。在方法EncodeRLP中是构建了一个私有的receiptRLP。
![交易回执](https://www.18btc.com/wp-content/uploads/2023/10/1007-81-7.png)
交易回执
从代码中可以看出 receiptRLP 仅仅包含上面提到的参与共识校验的内容。
![共识校验](https://www.18btc.com/wp-content/uploads/2023/10/1007-81-8.png)
共识校验
交易回执交易信息
这部分信息记录的是关于回执所对应的交易信息。
TxHash
交易回执所对应的交易哈希。
ContractAddress
当这笔交易是部署新合约时,记录新合约的地址。
GasUsed
这笔交易执行所消耗的Gas燃料。
这些信息不参与共识的原因是这三项信息已经在其他地方校验。
- TxHash: 区块有校验交易集的正确性。
- ContractAddress: 如果是新合约,实际上已经提交到以太坊状态 State 中。
- GasUsed: 已属于CumulativeGasUsed的一部分。
交易回执区块信息
这部分信息完全是为了方便外部读取交易回执,不但知道交易执行情况,还能方便的指定该交易属于哪个区块中第几笔交易。
- BlockHash: 交易所在区块哈希。
- BlockNumber: 交易所在区块高度。
- TransactionIndex: 交易在区块中的序号。
这三项信息,主要是在数据库 Leveldb 中读取交易回执时,实时指定。
![交易回执](https://www.18btc.com/wp-content/uploads/2023/10/1007-81-9.png)
交易回执
交易回执构造
交易回执是在以太坊虚拟机处理完交易后,根据结果整理出的交易执行结果信息。反映了交易执行前后以太坊变化以及交易执行状态。
以下是完整的交易回执构造代码。
![交易回执构造](https://www.18btc.com/wp-content/uploads/2023/10/1007-81-10.png)
交易回执构造
交易回执存储
交易回执作为交易执行中间产物,为了方便快速获取某笔交易的执行明细。以太坊中有跟随区块存储时实时存储交易回执。但为了降低存储量,只存储了必要内容。
首先,在存储时,将交易回执对象转换为精简内容。
精简内容是专门为存储定义的一个结构ReceiptForStorage。存储时将交易回执集进行RLP编码存储。
所以看存储了哪些内容,只需要看 ReceiptForStorage的 EncodeRLP方法:
根据EncodeRLP方法实现,可以得出在存储时仅仅存储了部分内容,且 Logs 内容同样进行了特殊处理LogForStorage。
![交易回执存储](https://www.18btc.com/wp-content/uploads/2023/10/1007-81-11。.jpg)
交易回执存储
交易回执示例
以下是etherscan上不同类型的交易回执数据。
一笔包含日志的交易回执
交易 0x01e180……0a4021 执行成功,且包含了两个事件日志。
![包含日志的交易回执](https://www.18btc.com/wp-content/uploads/2023/10/1007-81-12。。.jpg)
包含日志的交易回执
一笔成功部署合约的交易回执
如果是部署合约的交易,可以看到 contractAddress 有值。
![成功部署合约的交易回执](https://www.18btc.com/wp-content/uploads/2023/10/1007-81-13。.jpg)
成功部署合约的交易回执
一笔含 StateRoot的交易回执
和其他交易回执内容不同,在高度1035301 前的交易并无 status 字段,而是 root 字段。是在后续改进中去除 root 采用 status 的。
![含 StateRoot的交易回执](https://www.18btc.com/wp-content/uploads/2023/10/1007-81-14。.jpg)
含 StateRoot的交易回执
一笔交易失败的交易回执
如果是失败的交易,则 status为0。
![交易失败的交易回执](https://www.18btc.com/wp-content/uploads/2023/10/1007-81-15。.jpg)
交易失败的交易回执