LocalSecret: lowering consensus / block time breaks block timestamp progression

[turtlebasket]

Issue: Time progression is messed up when speeding up the block time.

I'm currently using the official block time speedup tutorial.

On a remote localsecret instance I created on August 9th, secretcli status returns:

Result	Correctness
"earliest_block_time":"2022-08-09T07:31:18.30567358Z"	✅
"latest_block_time":"2022-08-28T21:29:55.862437404Z"	❌

It's August 13th today, so as you can see, the current block time is over 2 weeks in the future. I suspect this is because the legacy block time from the old dev container is hardcoded instead of pulling the latest timestamp every block.

Please, please fix this when possible - being forced to use no block time speedup makes time-dependent contracts (vesting schedules, distributors, etc) a complete pain in the ass to reliably test and debug.

EDIT: Alternatively, displayed block time could be a separately-configured option to either match the present time of block commit or be a predetermined, higher value (which would effectively allow for fast-tracking any contract test that requires waiting)

[Cashmaney]

Thanks for the report. Though I'm not entirely sure that this isn't a feature in some cases. If I'm understanding correctly in this scenario with faster blocks I can simulate the passage of block height and time as they would appear on mainnet.

That being said - as you mentioned, this is probably something that should be available by config, as this is a case-by-case thing whether you want it this way or that

[assafmo]

Yeah just confirmed this locally, seems like a Tendermint bug :thinking:

[assafmo]

When doing this https://docs.scrt.network/secret-network-documentation/development/tools-and-libraries/local-secret#pro-tip-speed-up-block-time blocks are about 200ms but Tendermint thinks that each block is about ~1s. Maybe there is a subtle bug in the way we set these configs?

[turtlebasket]

Just coming back to this to post what we're currently using as a workaround (honestly works better than what we had before):

Instead of using local timestamps and physically waiting 5 seconds, we just get the sped up / future block time directly from the dev chain. We're using polar.js which has no option to do this, so we just called the REST endpoint directly.

async function getBlockTime() {
    let res = await fetch(endpoint + "/blocks/latest");
    let data = await res.json();
    let time = data.block.header.time;
    return Math.floor(new Date(time).valueOf() / 1000);
}

[assafmo]

This might indicate that the bug is in the RPC server :thinking:

[assafmo]

The fix: https://twitter.com/mikedotexe/status/1580762806101868546?t=2jtxmL1NIh7dnwIpUSysYw&s=19

time_iota_ms

[assafmo]

https://github.com/CosmWasm/mesh-security/tree/28ac88a58315c2faacf9ab479c377f59b3c8912a/ci-scripts/wasmd/scripts/setup_wasmd.sh#L13-L14

[assafmo]

This is now fixed in localsecret:v1.6.0-patch.1.