待处理的以太坊交易的日志在确认后消失了答案

【问题标题】：Logs of a pending ethereum transaction disappeared after confirmation待处理的以太坊交易的日志在确认后消失了
【发布时间】：2021-01-07 06:59:38
【问题描述】：

当我使用“eth_getLogs”查询待处理事务的日志时，日志信息显示如下，但在确认 tx 后，日志在 etherescan 上不可用。此 tx 使用了委托调用。任何人都可以就日志消失的原因提出建议吗？

在 tx 待处理时通过查询“eth_getLogs”来记录信息：

  topics: [
    '0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef',
    '0x0000000000000000000000006463bd6026a2e7bfab5851b62969a92f7cca0eb6',
    '0x000000000000000000000000860bd2dba9cd475a61e6d1b45e16c365f6d78f66'
  ],
  data: '0x00000000000000000000000000000000000000000000058677bb9e53cb507ddd',
  blockNumber: '0xb117d6',
  transactionHash: '0x9b51d7093c4507fa96af3fd4418c508700cb9f69f3cea9d7f5a192afa30cd1bf',
  transactionIndex: '0x41',
  blockHash: '0x0000000000000000000000000000000000000000000000000000000000000000',
  logIndex: '0x4f',
  removed: false
}

确认后在etherscan上的交易：https://etherscan.io/tx/0x9b51d7093c4507fa96af3fd4418c508700cb9f69f3cea9d7f5a192afa30cd1bf

【问题讨论】：

标签： ethereum solidity go-ethereum

【解决方案1】：

由于交易执行的结果，包括生成的事件，取决于执行时合约和账户的状态，那么，显然，显示的日志对应于如果交易被包含在区块中的状态0xb117d6，但是在block 0xb117d8的上下文中真正执行的时候，状态block/account已经不同，导致结果不同。

另外，未决交易执行的预测是基于你的特定节点的数据，在分叉的情况下，可能与主链的数据不同。

【讨论】：

感谢@Mad Jackal 的回答，我在上面的另一个答案中发表了我的理解。我的理解正确吗？

【解决方案2】：

@Mad Jacal 感谢您的回答！我的理解正确吗？

假设有这样的合同：

contract test {
    bool isTrue = true;
    function foo() public {
        if (isTrue) {
            emit Event(..)
        } else {
            return;
        }
    }
    function changeToFalse() public {
        isTrue = false;
    }
}

第一个调用者调用“foo”函数，第二个调用者调用“changeToFalse”函数。两个 tx 位于同一个区块中，但由于 gas 价格较高，第二个调用者的 tx 位于第一个调用者的 tx 前面。如果节点还没有听到第二个调用者的 tx，挂起的日志将显示事件日志。这是你的意思吗？

【讨论】：

是的，它可以有这个效果。严格来说，如果矿工都在队列中，就无法预测交易的执行顺序。