[v0] wrong `Timestamp` in v0.gwscan.com/tx and v0.gwscan.com/block views

[Flouse]

The Timestamp shown in https://v0.gwscan.com/tx/0x53c5407321855bc9fb56bd9bf1141630f30248305e811a9061e927b0ea14fdc3 is 2022/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.

# Request
curl https://mainnet.godwoken.io/rpc/ \
  --header 'Content-Type: application/json' \
  -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0xbf225f9c4bcd794be3501f3c6c8c7322226b2e3c39140a0cefe332538d57b46b", false],"id":1}'

# result
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "number": "0x19163",
    "hash": "0xbf225f9c4bcd794be3501f3c6c8c7322226b2e3c39140a0cefe332538d57b46b",
    "parentHash": "0x900a097f771bc8eff4bac6e79babad4bc239137ba57c85beca3c2f77d5d2a69a",
    "gasLimit": "0x2e555892",
    "gasUsed": "0x120d9b7",
    "miner": "0x7b8d17ee0252181b84f8ee28fdd1299886803c55",
    "size": "0xba4",
    "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
    "transactions": [...,
      "0x53c5407321855bc9fb56bd9bf1141630f30248305e811a9061e927b0ea14fdc3",...
    ],
    "timestamp": "0x61f11318",
    ...
    "difficulty": "0x8e1bc9bf04000",
    "totalDifficulty": "0x8e1bc9bf04000",
  }
}

"timestamp": "0x61f11318" = 1643189016

-> GMT | Wed Jan 26 2022 09:23:36 GMT+0000

[zmcNotafraid]

Before we display block's inserted_at as timestamp.Now we display block's real timestamp from rpc. @Flouse

[Keith-CY]

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

[Flouse]

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.

[Keith-CY]

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

[Flouse]

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

Conclusion

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.