[Help] Breaking indexers due to not existing transactions #2079
-
ContextWhen looking for events, we expect that the ProblemExample of an invalid event: curl --location --request POST 'https://celo-mainnet.infura.io/v3/apikey' \
--header 'Content-Type: application/json' \
--data-raw '{"jsonrpc":"2.0","method":"eth_getLogs",
"params":[
{
"address": "0x471EcE3750Da237f93B8E339c536989b8978a438",
"fromBlock": "0x122d480",
"toBlock":"0x122d480",
"topics":["0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef", "0x0000000000000000000000000000000000000000000000000000000000000000", "0x000000000000000000000000ce10d577295d34782815919843a3a4ef70dc33ce"]
}
],"id":1}' Response is: {
"jsonrpc": "2.0",
"id": 1,
"result": [
{
"address": "0x471ece3750da237f93b8e339c536989b8978a438",
"blockHash": "0x6792f5028a5cb4bc6fdb7077a632a3133431b9c5e544adc71880569f508d8c6a",
"blockNumber": "0x122d480",
"data": "0x000000000000000000000000000000000000000000000003defc23f5746757c1",
"logIndex": "0x1e9",
"removed": false,
"topics": [
"0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
"0x0000000000000000000000000000000000000000000000000000000000000000",
"0x000000000000000000000000ce10d577295d34782815919843a3a4ef70dc33ce"
],
"transactionHash": "0x6792f5028a5cb4bc6fdb7077a632a3133431b9c5e544adc71880569f508d8c6a",
"transactionIndex": "0x6"
}
]
} AsksIs this expected (as CELO is the only network where we are seing this behaviour)? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 2 replies
-
Yes this is expected behavior, here is a short description of Celo's notion of a Block Transaction SummaryA Block Transaction on Celo is a type of transaction initiated by the system, designed to emit events related to system-orchestrated operations. These operations often involve the distribution of epoch rewards or setting new gas price minimums. Because events cannot be emitted if not included in a block, a Block Transaction is created. Block Transactions enable Celo to carry out unique transaction types and offer visibility into events emerging from non-user-generated transactions within a block. Importantly, Block Transactions have a transaction hash identical to their respective block hash. This is not due to a cryptographic collision, but rather a deliberate assignment for identification purposes? An example of a Block Transaction is seen at the close of each epoch, where transactions from the EpochRewards contract are included in the final block. RPC QueryBlock Transactions are not listed when querying an RPC for transactions but are visible when retrieving the logs. During an RPC query, if you come across a transaction whose hash matches the block hash, you have identified a Block Transaction. This signals it is system-generated and not created by a standard user. |
Beta Was this translation helpful? Give feedback.
-
Hi, this decision sounds unnatural to me, as events are always generated by contract execution on the EVM, but in this case there's no code execution on the EVM, some internal tasks are performed at the protocol level and then you emit a event. This sounds very confusing and I bet our indexer will not be the only ethereum tool that will break due to this behaviour. IMHO the proper way to do this is having a transaction with the proper data and generated events (introduced by the node/validators), so it can be easily audited and processed. |
Beta Was this translation helpful? Give feedback.
I appreciate the feedback you've given here - our team is considering solutions very similar to what you have mentioned here - related transactions introduced by validators.
In the interim however, Block Transactions should be taken into account when a transaction is identified to have the same hash as its block.