feat(jsonrpc): add blockTimestamp to logs and receipts#6671
feat(jsonrpc): add blockTimestamp to logs and receipts#66710xbigapple wants to merge 1 commit intotronprotocol:developfrom
Conversation
|
|
||
| // Set logs | ||
| List<TransactionLog> logList = new ArrayList<>(); | ||
| String blockTimestamp = ByteArray.toJsonHex(txInfo.getBlockTimeStamp() / 1000); |
There was a problem hiding this comment.
Why do you need to convert timestamp to this format ByteArray.toJsonHex(txInfo.getBlockTimeStamp() / 1000)
There was a problem hiding this comment.
The conversion to ByteArray.toJsonHex(... / 1000) is correct for the JSON-RPC surface.
TransactionInfo.blockTimeStamp is stored in TRON internal milliseconds, while the Ethereum-compatible JSON-RPC layer uses hex-encoded Unix seconds for timestamp quantities. This is also consistent with the existing block-level timestamp field in BlockResult, which serializes blockCapsule.getTimeStamp() / 1000 via ByteArray.toJsonHex(...).
My concern here is the source rather than the format: this constructor already has blockCapsule, so the canonical value for a receipt log's blockTimestamp should come from the containing block. If txInfo.getBlockTimeStamp() is unset/default in older or partially populated records, this can serialize 0x0 even though the block has a real timestamp. Please switch this to blockCapsule.getTimeStamp(), or at least add an explicit fallback when txInfo.getBlockTimeStamp() == 0.
| Assert.assertEquals(transactionReceipt.getLogs()[0].getBlockNumber(), "0x1"); | ||
| Assert.assertEquals(transactionReceipt.getLogs()[0].getTransactionHash(), "0x31"); | ||
| Assert.assertEquals(transactionReceipt.getLogs()[0].getTransactionIndex(), "0x0"); | ||
| Assert.assertEquals(transactionReceipt.getLogs()[0].getBlockTimestamp(), "0x3e8"); |
There was a problem hiding this comment.
Good to assert the concrete value here.
However, this is still a constructor-level unit test, while the feature request is specifically about the public JSON-RPC response shape. Please also add an API-facing assertion in JsonrpcServiceTest that eth_getTransactionReceipt and eth_getBlockReceipts expose blockTimestamp with the expected hex-seconds value on the serialized response. The existing receipt equality check is useful, but it can still miss a false positive if both paths shape the same incomplete object.
| LogFilterElement logFilterElement1 = elementList.get(0); | ||
| LogFilterElement logFilterElement2 = elementList2.get(0); | ||
|
|
||
| Assert.assertEquals("0x3e8", logFilterElement1.getBlockTimestamp()); |
There was a problem hiding this comment.
This is the right kind of value assertion, but it only verifies the construction helper.
Since the compatibility change is on the external JSON-RPC response model, we should also add endpoint-level coverage for eth_getLogs, eth_getFilterLogs, and log-type eth_getFilterChanges to prove that the new field is actually present on the API boundary, not just on the intermediate object.
4 participants
What does this PR do?
Adds the
blockTimestampfield to the log objects returned by JSON-RPC event and receipt query interfaces, aligning the TRON JSON-RPC implementation with the Ethereum execution-apis specification. close #6617Specifically, it updates:
LogFilterElement(used ineth_getLogs,eth_getFilterLogs,eth_getFilterChanges(about log/event filter)) to includeblockTimestamp.TransactionLogwithinTransactionReceipt(used ineth_getTransactionReceipt,eth_getBlockReceipts) to includeblockTimestamp.The timestamp is extracted from the corresponding
TransactionInfo'sblockTimeStamp, divided by 1000 to convert to seconds, and returned as a hexadecimal string (e.g.,"0x3e8").Why are these changes required?
To maintain compatibility with the evolving Ethereum JSON-RPC API standards. Adding the block generation timestamp directly to the log objects enables developers and dApps to process event streams with precise time context without needing to perform secondary
eth_getBlockByHash/Numberqueries, significantly reducing network overhead and improving client efficiency.This PR has been tested by:
LogMatchExactlyTest.javato verifyblockTimestampinLogFilterElement.TransactionReceiptTest.javato verifyblockTimestampinTransactionReceipt.TransactionLog.Follow up
Extra details