I cannot get results from api eth_getLogs sometimes

[liuyifei001]

Software Versions

OS : Linux
JVM : Oracle Corporation 1.8.0_161 amd64
Git : a8ad2a169e58946b5b8de6ecf7b7ef5b8db05aff
Version : 4.7.5
Code : 18306

Expected behavior

If the JSON-RPC service is enabled, users should be able to search for events based on contract addresses and topics. However, after I enabled the service, there should be an address-related log in a certain block, but I couldn't find it.

Actual behavior

I use the following interface to get events:

curl --location 'http://localhost:8545/jsonrpc' --header 'Content-Type:application/json' --data '{
    "jsonrpc": "2.0",
    "method": "eth_getLogs",
    "params": [
        {
            "address":[
                "0x034e5a6bbf5d4bacd1c92c4a9bd2a67554c755a5"
            ],
            "fromBlock": "0x30f22c0",
            "toBlock":"0x30f22c0"
        }
    ],
    "id": 1
}'

And get nothing:

{"jsonrpc":"2.0","id":1,"result":[]}

But the following log really exists in block 51323584("0x30f22c0"):

        {
            "address": "0x034e5a6bbf5d4bacd1c92c4a9bd2a67554c755a5",
            "blockHash": "0x00000000030f22c0a2db59c5b94ca345ef97ff3ec3eef3cd45863907cabd04f8",
            "blockNumber": "0x30f22c0",
            "data": "0x0000000000000000000000006e0617948fe030a7e4970f8389d4ad295f249b7e0000000000000000000000000000000000000000000000000000000000000000",
            "logIndex": "0x44",
            "removed": false,
            "topics": [
                "0xcdee897399ab5e465acb1bd3ed5e32c695f196321764546c59720fa6c9ce4c69"
            ],
            "transactionHash": "0xb2c4a682fdfe6352b93ef79fa7b890ac5daf7f6a240f52e2b528c5f1c817a96f",
            "transactionIndex": "0xe5"
        },

I used the same interface with the JSON parameter and dropped the ‘address’ to verify it:

curl --location 'http://localhost:8545/jsonrpc' --header 'Content-Type:application/json' --data '{
    "jsonrpc": "2.0",
    "method": "eth_getLogs",
    "params": [
        {
            "fromBlock": "0x30f22c0",
            "toBlock":"0x30f22c0"
        }
    ],
    "id": 1
}'

I tried to use another address 0xa614f803b6fd780986a42c78ec9c7f77e6ded13c and got the log successfully.

Frequency

I have no idea. But I have not gotten logs using the address 0x034e5a6bbf5d4bacd1c92c4a9bd2a67554c755a5 in other blocks yet.

[abn2357]

I think at least you can try more addresses to pinpoint whether the problem lies with the interface or some special address as '0x034e5a6bbf5d4bacd1c92c4a9bd2a67554c755a5'

[317787106]

@liuyifei001 I find the same problem using https://api.trongrid.io/jsonrpc. It seems a little complicated.

[liuyifei001]

I think at least you can try more addresses to pinpoint whether the problem lies with the interface or some special address as '0x034e5a6bbf5d4bacd1c92c4a9bd2a67554c755a5'

@abn2357 I have found another address TUvDoufTvAQcb8ATHCk2HroKUZ1ohYoX2j in block 65359089:

curl --location 'https://api.trongrid.io/jsonrpc' --header 'Content-Type: application/json' --data '{
    "jsonrpc": "2.0",
    "method": "eth_getLogs",
    "params": [
        {
            "address":[
                "0xcfd9d0f827204e7ef358aa3c1424a16e314a4794"
            ],
            "fromBlock": "0x3e54cf1",
            "toBlock":"0x3e54cf1"
        }
    ],
    "id": 1
}'

and it returns:

{"jsonrpc":"2.0","id":1,"result":[]}

But really there are related log in this block：

{
            "address": "0xcfd9d0f827204e7ef358aa3c1424a16e314a4794",
            "blockHash": "0x0000000003e54cf16f5e89dfe14504d1ca85586b433773d02c3a482f2fb7be2b",
            "blockNumber": "0x3e54cf1",
            "data": "0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000645a6866990000000000000000000000000000000000000000000000000213e90993a67f700000000000000000000000000000000000000000000000000000000066f4f7ac000000000000000000000041b592c0fedf1a87e253f7099115ebcd59857ae4d5",
            "logIndex": "0x10",
            "removed": false,
            "topics": [
                "0x5a68669900000000000000000000000000000000000000000000000000000000",
                "0x0000000000000000000000004cb2759c3b2a5783707349e7dd7aae95f955b5d4",
                "0x0000000000000000000000000000000000000000000000000213e90993a67f70",
                "0x0000000000000000000000000000000000000000000000000000000066f4f7ac"
            ],
            "transactionHash": "0xfe774dd02fb73a87f1d3a12b2f0c694b0bb63c1cdf3886b530eaa423c0763a5b",
            "transactionIndex": "0x28"
        },

[liuyifei001]

@liuyifei001 I find the same problem using https://api.trongrid.io/jsonrpc. It seems a little complicated.

@317787106 Any further progress?

[317787106]

I have found the root cause. For the same topic or address, bit indexes in query are diffenent from that in write logic. Generally, there are 3 different bits in write logic:

So we initiate the length of array to 3, default 0 in query logic:

But actually, there maybe duplicate bit indexes in write logic, namely mov1 == mov2 or mov1 == mov3, although the probability is very small. So default value (0) in query logic is no necessary condition. The solutuion is to create the ArrayList instead of an array with fixed length 3 in query logic.

[DongDongSunny]

I found the the "address":[
"0x034e5a6bbf5d4bacd1c92c4a9bd2a67554c755a5"
], convert to TAGgtiB8qsubF7gdz6KAwwf9mBbVQZdnYC is not activated yet. That probably is one reason

[317787106]

I found the the "address":[ "0x034e5a6bbf5d4bacd1c92c4a9bd2a67554c755a5" ], convert to TAGgtiB8qsubF7gdz6KAwwf9mBbVQZdnYC is not activated yet. That probably is one reason

When we write bloom of blocks' event into db, the condition of whether address is activated is beyond our consideration. Even if it is not activated, we will also write its bloom.

[Murphytron]

This issue has been added to the tronprotocol/pm#102, welcome to share the latest progress @317787106 , and discuss together with @liuyifei001 @abn2357 @DongDongSunny .

[317787106]

We can calculate the possibility of hash collision. the collision means that, among the three functions, at least two hash function values ​​(between 0 and 2047) correspond to the same position. And this possibilty is:
$$(C_{2048}^1 + C_{2048}^2 )/(C_{2048}^1 + C_{2048}^2 + C_{2048}^3)$$

[317787106]

According to incomplete statistics, I find that 3700 contract addresses have hash collision among 2.5 million contract.