Transaction/receipts data returned by Anvil is inconsistent with Ethereum spec

[mslipper]

Component

Anvil

Have you ensured that all of these are up to date?

• Foundry
• Foundryup

What version of Foundry are you on?

0.1.0 (a43313a 2022-11-30T17:15:08.718900657Z)

What command(s) is the bug in?

anvil fork

Operating System

Linux

Describe the bug

Overview

Optimism derives L2 blocks from log events and calldata submitted to L1. To prevent attacks from a malicious RPC provider, our system performs a series of sanity checks as well as a receiptsRoot check to verify that log events are valid and none are missing. While testing our op-node against a fork of L1 Goerli using Anvil, we observed these checks failing in the below ways.

Mismatch between the logIndex field and actual log index

The logIndex field sometimes doesn't match the actual index the log appears in the RPC. Here's cast output from one of the affected receipts:

➜  ~ cast receipt 0x2676dfb732072e733fe40dc6bb466808ef4ac3ddf71d5d32502502241449bbee --rpc-url <rpc-url>

blockHash               0xd28140f6b523d36cd7fba9594a7b58cb354aeafae1ce9be9cb992f9b0542f98c
blockNumber             8083603
contractAddress
cumulativeGasUsed       178140
effectiveGasPrice       1000000000
gasUsed                 86860
logs                    [{"address":"0xc2beaa06e18ab001fcf4318030c31c334c71d500","topics":["0xa7aaf2512769da4e444e3de247be2564225c2e7a8f74cfe528e46e17d24868e2","0xc2c2ee83a423d279138ab45d7de00bc85c70bc133ab2af5b4e53f885f5bef170","0x0000000000000000000000000000000000000000000000000000000000000001","0x00000000000000000000000000000000000000000000000000000000638ed10c"],"data":"0x0000000000000000000000000000000000000000000000000000000000312d1c","blockHash":"0xd28140f6b523d36cd7fba9594a7b58cb354aeafae1ce9be9cb992f9b0542f98c","blockNumber":"0x7b5893","transactionHash":"0x2676dfb732072e733fe40dc6bb466808ef4ac3ddf71d5d32502502241449bbee","transactionIndex":"0x1","logIndex":"0x1","transactionLogIndex":"0x0","removed":false}]
logsBloom               0x00010000001000000000000001000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000040000000000000000000000008001000000000000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000010000000000004000000000900000000000200000000000000000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000000000
root
status                  1
transactionHash         0x2676dfb732072e733fe40dc6bb466808ef4ac3ddf71d5d32502502241449bbee
transactionIndex        1
type

You'll see that the logIndex in the first log above is 0x1, when it should be 0x0.

Computed receipts root does not match returned receiptsRoot

When we compute a receipt root for a given block using all the the transaction receipts within it, the computed receipts root does not match the receiptsRoot within the block.

Unfortunately, I don't know exactly why this is. We've verified that our receipts root computation works by running the same code against Goerli with no issue. I wish I had more concrete information about the root cause here, but I'm fairly confident that you can reproduce this yourself by performing the same computation we do on an Anvil block with receipts in it. Here's the code we're using to compute the root, in case it helps: https://github.com/ethereum-optimism/optimism/blob/develop/op-node/sources/receipts.go#L65-L72.

Transaction hashes are duplicated

We're also seeing cases where transaction hashes appear in multiple blocks. Relevant cast output is below:

➜  ~ cast block 8083936 --rpc-url <rpc url>


baseFeePerGas        0
difficulty           0
extraData            0x
gasLimit             30000000
gasUsed              0
hash                 0xa0de39cbb463b35e5cd9b29a212ff6bdb0734c6f86e7ab04188a796f8c27aa11
logsBloom            0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
miner                0x0000000000000000000000000000000000000000
mixHash              0x0000000000000000000000000000000000000000000000000000000000000000
nonce                0x0000000000000000
number               8083936
parentHash           0xc85e0ecde7349938f6daea79d6834dc278fe05e305dca5fc94a80a9d923dfe16
receiptsRoot         0xa1d38b83ec14e13227c918362bd5ad07a7ea3ea830853ef3b181dfad043564d0
sealFields           [
	0x0000000000000000000000000000000000000000000000000000000000000000
	0x0000000000000000
]
sha3Uncles           0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347
size                 633
stateRoot            0x0000000000000000000000000000000000000000000000000000000000000000
timestamp            1670308008
totalDifficulty      10790000
transactions:        [
	0xc9f5537c71d2e8aaf1a7f5884acfbe1b6df77d773bb7b4569843f7fe7601d3d4
]
➜  ~ cast block 8083956 --rpc-url <rpc url>


baseFeePerGas        0
difficulty           0
extraData            0x
gasLimit             30000000
gasUsed              0
hash                 0xc6449f40c413ba7bebdcba3f620fecfe958a6c109a21aeb7ff522f4149fabc5b
logsBloom            0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
miner                0x0000000000000000000000000000000000000000
mixHash              0x0000000000000000000000000000000000000000000000000000000000000000
nonce                0x0000000000000000
number               8083956
parentHash           0x9198cd3b82e3892626f4a366baa05afd6d3c476598d7e96d0484ca7bcb69b235
receiptsRoot         0xa1d38b83ec14e13227c918362bd5ad07a7ea3ea830853ef3b181dfad043564d0
sealFields           [
	0x0000000000000000000000000000000000000000000000000000000000000000
	0x0000000000000000
]
sha3Uncles           0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347
size                 633
stateRoot            0x0000000000000000000000000000000000000000000000000000000000000000
timestamp            1670308248
totalDifficulty      10790000
transactions:        [
	0xc9f5537c71d2e8aaf1a7f5884acfbe1b6df77d773bb7b4569843f7fe7601d3d4
]

We're able to work around these issues for now, but I thought I'd bring them to your attention anyway. Thanks for everything y'all do! Foundry is integral to our development process.

[rkrasiuk]

hey @mslipper, could you pls tell me which chains these txs/blocks are from? if that's local, is there any way to repro?

[0x6e616d]

@mslipper @rkrasiuk
Do you resolve this problem? I faced the same error when using the fork network.

The receipts of the block are:

{
    "jsonrpc": "2.0",
    "id": 1,
    "result": [
        {
            "transactionHash": "0x6dfe8f4a3556854809fc1d49787ed90b8e8b812bf3a8357958360aab21d40c70",
            "transactionIndex": "0x0",
            "blockHash": "0xbc3b4ad6210408931e808a919800ca06a11a0d19dbca068bc0333cf2f7c3a6b7",
            "blockNumber": "0x12a6f23",
            "cumulativeGasUsed": "0x65b8",
            "gasUsed": "0x65b8",
            "effectiveGasPrice": "0x3b9aca03",
            "from": "0x3c44cdddb6a900fa2b585dd299e03d12fa4293bc",
            "to": "0xff00000000000000000000000000000000000901",
            "contractAddress": null,
            "logs": [],
            "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
            "status": "0x1",
            "type": "0x2",
            "deposit_nonce": null
        },
        {
            "transactionHash": "0x2ef236a2336eb03e44aa4ce3f89ea5303dcc91dab50b7e2c454270644af3e6c5",
            "transactionIndex": "0x1",
            "blockHash": "0xbc3b4ad6210408931e808a919800ca06a11a0d19dbca068bc0333cf2f7c3a6b7",
            "blockNumber": "0x12a6f23",
            "cumulativeGasUsed": "0x1c143",
            "gasUsed": "0x15b8b",
            "effectiveGasPrice": "0x3b9aca03",
            "from": "0x70997970c51812dc3a010c7d01b50e0d17dc79c8",
            "to": "0xb6aa91e8904d691a10372706e57ae1b390d26353",
            "contractAddress": null,
            "logs": [
                {
                    "address": "0xb6aa91e8904d691a10372706e57ae1b390d26353",
                    "topics": [
                        "0xa7aaf2512769da4e444e3de247be2564225c2e7a8f74cfe528e46e17d24868e2",
                        "0x90f2770713ba137c167e7a4b409567ac2ede9c7cd96c966e989e6cc6621cde4e",
                        "0x0000000000000000000000000000000000000000000000000000000000000001",
                        "0x0000000000000000000000000000000000000000000000000000000000000014"
                    ],
                    "data": "0x00000000000000000000000000000000000000000000000000000000660a2322",
                    "blockHash": "0xbc3b4ad6210408931e808a919800ca06a11a0d19dbca068bc0333cf2f7c3a6b7",
                    "blockNumber": "0x12a6f23",
                    "transactionHash": "0x2ef236a2336eb03e44aa4ce3f89ea5303dcc91dab50b7e2c454270644af3e6c5",
                    "transactionIndex": "0x1",
                    "logIndex": "0x1",
                    "removed": false
                }
            ],
            "logsBloom": "0x00000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000002000000000000000000000040000000000000000000000000000000000000000000001040000000000000000000000000000000000000002000000000000000000024000000000000000000000000000000000000000200000000000000000000000000400000000000004000000000800000000000020000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000080000000000000040000000000000000000000000000000000000000000000000000000000000000000",
            "status": "0x1",
            "type": "0x2",
            "deposit_nonce": null
        }
    ]
}

The log index in the second transaction should be "0x0:, but it is "0x1"

[grandizzy]

The log index in the second transaction should be "0x0:, but it is "0x1"

@0x6e616d could you please add details of the commands you used / forked chain to investigate this issue? thank you

[0x6e616d]

The log index in the second transaction should be "0x0:, but it is "0x1"

@0x6e616d could you please add details of the commands you used / forked chain to investigate this issue? thank you

It's been quite a long time, and I forgot about it. Let me check again