fix timestamp differences

[rjnrohit]

Fixes Closes Resolves #

Please choose one of the keywords above to refer to the issue this PR solves followed by the issue number (e.g. Fixes #000). If no issue number, remove the line. Also, remove everything marked optional that is not applicable. Remove this note after reading.

Changes

• List the changes

Types of changes

What types of changes does your code introduce?

• Bugfix (a non-breaking change that fixes an issue)
• New feature (a non-breaking change that adds functionality)
• Breaking change (a change that causes existing functionality not to work as expected)
• Optimization
• Refactoring
• Documentation update
• Build-related changes
• Other: Description

Testing

Requires testing

• Yes
• No

If yes, did you write tests?

• Yes
• No

Notes on testing

Optional. Remove if not applicable.

Documentation

Requires documentation update

• Yes
• No

If yes, link the PR to the docs update or the issue with the details labeled docs. Remove if not applicable.

Requires explanation in Release Notes

• Yes
• No

If yes, fill in the details here. Remove if not applicable.

Remarks

Optional. Remove if not applicable.

[LukaszRozmej]

Maybe it fits better in JsonRcpConfig?

[rjnrohit]

Yes, we can do it if we want to make it configurable.

[MarekM25]

Have you discussed it with Geth Devs? I think 12 seconds is better. What is the reasoning for 1nd?

[LukaszRozmej]

Have you discussed it with Geth Devs? I think 12 seconds is better. What is the reasoning for 1nd?

Yes this is actually unifying eth_simulate space. Main reasoning is to have similar cross-chain behaviour. User can provide overrides for it if he wants.

[rjnrohit]

Have you discussed it with Geth Devs? I think 12 seconds is better. What is the reasoning for 1nd?

Yes, I had a call with the eth_simulate devs teams; geth has 1 second increment, you can check from here: https://github.com/s1na/go-ethereum/blob/f25fcd34e11061568c187c44dd02fb6e9c8546de/internal/ethapi/simulate.go#L48

[MarekM25]

Have you discussed it with Geth Devs? I think 12 seconds is better. What is the reasoning for 1nd?

Yes this is actually unifying eth_simulate space. Main reasoning is to have similar cross-chain behaviour. User can provide overrides for it if he wants.

yes, so that's why our SecondsPerSlot can be used, providing overrides sounds worse

[MarekM25]

Have you discussed it with Geth Devs? I think 12 seconds is better. What is the reasoning for 1nd?

Yes, I had a call with the eth_simulate devs teams; geth has 1 second increment, you can check from here: https://github.com/s1na/go-ethereum/blob/f25fcd34e11061568c187c44dd02fb6e9c8546de/internal/ethapi/simulate.go#L48

but why? I think the better approach would be to do SecondsPerSlot and this value is configurable

[MarekM25]

I don't think we need a seperate config value for this, either hardcode 1 and people will override it through RPC -> like geth
or just do what we are doing now and discuss with the geth team

[rjnrohit]

I don't think we need a seperate config value for this, either hardcode 1 and people will override it through RPC -> like geth or just do what we are doing now and discuss with the geth team

right now it is hardcoded to 1 , I'll make it configurable as well via moving the variable to the jsonRpcConfig

[rjnrohit]

I don't think we need a seperate config value for this, either hardcode 1 and people will override it through RPC -> like geth or just do what we are doing now and discuss with the geth team

for geth, it is completely hardcoded and not configurable either

[MarekM25]

I don't think we need a seperate config value for this, either hardcode 1 and people will override it through RPC -> like geth or just do what we are doing now and discuss with the geth team

for geth, it is completely hardcoded and not configurable either

https://github.com/s1na/go-ethereum/pull/new/simulate/timestamp-default