feat: implement getInsecureTime precompile

[pistomat]

📝 Summary

Implementation of the getInsecureTime precompile that returns the Kettle Unix time.

Considerations

• The description, name and address of the precompile are up for debate.
• When the precompile is used in a normal Suave transaction, it should probably return block time.
• Is the E2E test enough?

📚 References

---

• I have seen and agree to CONTRIBUTING.md

[dmarzzz]

would be good to add ", insecure because it assumes trust in Kettle's clock" or something like that to the description plz

[zeroXbrock]

To really ensure the precompile isn't returning a bogus number (although the code is sound; I'm sure it won't), you could also check the system time after calling the precompile, so that you could ultimately assert start_time $\le$ precompile_time $\le$ now_time.

But otherwise the code is solid. Thanks for the PR @pistomat!

[dmarzzz]

To really ensure the precompile isn't returning a bogus number (although the code is sound; I'm sure it won't), you could also check the system time after calling the precompile, so that you could ultimately assert start_time ≤ precompile_time ≤ now_time.

Good idea, maybe we should add some basic checks also to the precompile so even if the TEE operator does mess with it, there are bounds? ideally shouldnt be a time before chain genesis time or outside of latest_block_num * 2 seconds + genesis_start_time ? It's not great because the operator could stop any blocks coming in, but it does make it slightly harder to manipulate I would argue. There's probably more we could do to make it harder also

[pistomat]

Nice idea!

The bounds should be suave block.timestamp <= value returned from the precompile <= suave block.timestamp + 2 seconds, right?

Also FYI I chose uint256 as return value because that is the type of block.timestamp.

[ferranbt]

Good call on the boundary checks. LGTM otherwise.

[pistomat]

Is this precompile also be available in normal Suave onchain transactions (not CCR)? @dmarzzz @ferranbt If so, I think we should also set the return value to the suave block.timestamp for that case. Because otherwise all validating nodes will get different values for this precompile which will probably break stuff.

This does not matter for CCRs, because they are processed only on a single Kettle, as opposed to Suave blocks, where all precompile return values should be deterministic (otherwise you can't validate blocks).

[ferranbt]

Is this precompile also be available in normal Suave onchain transactions (not CCR)? @dmarzzz @ferranbt If so, I think we should also set the return value to the suave block.timestamp for that case. Because otherwise all validating nodes will get different values for this precompile which will probably break stuff.

This does not matter for CCRs, because they are processed only on a single Kettle, as opposed to Suave blocks, where all precompile return values should be deterministic (otherwise you can't validate blocks).

This precompile is not available on the Suave chain, only in the CCR context.

[pistomat]

Updated the description @dmarzzz.

In the end I did not add any bounds for the time returned, because the lower bound of block.timestamp can be easily checked in Solidity and the upper bound cannot be simply adding block frequency (3 seconds) because of missed slots (which for Toliman happen like 6 times a day on average). So for me it is ready to merge.

P.S. I will add a PR to the suave-std repo to call this precompile after this one is merged.

[ferranbt]

P.S. I will add a PR to the suave-std repo to call this precompile after this one is merged.

Nice! I will run the CI and merge if it passes.

You do not need to update suave-std, it is done automatically.

[pistomat]

Updated the precompile to use milliseconds instead of seconds