runtime-sdk: block.timestamp is return the timestamp of previous block.

[roynguyen]

Hi oasis team.
When I develop smart contract on emerald paratime, I emit block.timestamp to check with current block timestamp: https://explorer.oasis.io/testnet/emerald/tx/0x1ea9094d3c1e0b2e1565b9835bc78ea8059e9e59038304de2ec975abb7448b58. I saw that it was return the timestamp of previous block 13263665 is 0x68ca390c and current block is 13263666. I checked with your implement of block_timestamp when start EVM:
fn block_timestamp(&self) -> U256 {
self.backend.ctx.runtime_header().timestamp.into()
}
when we start EVM, we pass block_timestamp by timestamp of current runtime_header? and this is the reason?

[kostko]

That is correct, the timestamp of the next block is not yet known at that point (as it requires consensus).

[roynguyen]

Can we add consensus next block time to current runtime? @kostko

[kostko]

The way the blocks are executed, this is currently not possible as the exact consensus timestamp is not known at the time of execution (because the block timestamp is defined by the timestamp of the consensus block in which the consensus layer finalized all of the execution commitments -- which comes at some point after execution).

What is the use case you have in mind where this would be important?

[roynguyen]

The main use case is our Fixed-Yield Locked Staking Pool. Smart contracts need to calculate lock periods, maturity dates, early withdrawal fees, and yield accruals.

All of these depend on block.timestamp to know exactly when a stake started and how many days remain. If the timestamp is off by one block, it breaks fee calculation, redemption timing, and payout accuracy.