Closed Flouse closed 1 year ago
Before we display block's inserted_at as timestamp.Now we display block's real timestamp from rpc. @Flouse
Before we display block's inserted_at as timestamp.Now we display block's real timestamp from rpc. @Flouse
I remember that the timestamp in the block is affected by the blocks in layer 1, so v0 shows the update time of database. Does it matter to revert it to timestamp of a block
As an optimistic rollup solution on CKB, Godwoken's rollup transaction containing layer-2 block information is committed to its layer-1 CKB.
Once a layer-1 block containing the layer-2 rollup transaction has enough confirmations, the timestamps of the layer-1 and layer-2 block are finalized.
In other words, the historical blocks are immutable, protected by the security of CKB.
As an optimistic rollup solution on CKB, Godwoken's rollup transaction containing layer-2 block information is committed to its layer-1 CKB.
Once a layer-1 block containing the layer-2 rollup transaction has enough confirmations, the timestamps of the layer-1 and layer-2 block are finalized.
In other words, the historical blocks are immutable, protected by the security of CKB.
The definition is clear, but the timestamp in a block was incorrect, as I recalled. But it's not recorded in our issue, so the chat history is used as a reference here
So the inaccuracy of the timestamp has been fixed, am I right
The definition is clear, but the timestamp in a block was incorrect, as I recalled. But it's not recorded in our issue, so the chat history is used as a reference here
It might be a previous wrong suggestion.
The layer-2 block's timestamp usually differs from the real-world time by a few minutes, because it's calculated from median timestamp of the last 37 CKB blocks. This is still the status quo. Please refer to https://docs.godwoken.io/faq#why-the-layer-2-block-timestamp-is-inaccurate
IMO, the data field GwScan.chaindata_index_db.block.inserted_at
is not on-chain data, and may be changed when the GwScan chaindata_index_db
is recreated.
So, I think GwScan.chaindata_index_db.block.inserted_at
is not suitable to be used as block.timestamp showed in GwScan, especially for a old block.
The
Timestamp
shown in https://v0.gwscan.com/tx/0x53c5407321855bc9fb56bd9bf1141630f30248305e811a9061e927b0ea14fdc3 is2022/04/18 14:56:02
, which is not accurate.Let's check the right timestamp through Godwoken v0 RPC
Although there isn't a
timestamp
field in the result of eth_getTransactionByHash, we could define the timestamp of a transaction by its block timestamp.The Godwoken v0 transaction(0x53c5407321855bc9fb56bd9bf1141630f30248305e811a9061e927b0ea14fdc3)'s layer2 block number is 102,755, and the blockhash is 0xbf225f9c4bcd794be3501f3c6c8c7322226b2e3c39140a0cefe332538d57b46b. The eth_getBlockByHash RPC could help get the correct info.
"timestamp": "0x61f11318" = 1643189016
-> GMT | Wed Jan 26 2022 09:23:36 GMT+0000