anvil's block timestamp interval does not go below 1s

[transmissions11]

Component

Anvil

Have you ensured that all of these are up to date?

• Foundry
• Foundryup

What version of Foundry are you on?

anvil 0.2.0 (a470d63 2024-05-16T00:20:38.420768000Z)

What command(s) is the bug in?

anvil --block-time 0.01

Operating System

macOS (Apple Silicon)

Describe the bug

When setting --block-time to a value <1s (e.g. 0.01s), blocks will be created at the desired <1s rate, but block timestamps will still increase by 1s for each block. This results in block.timestamp rapidly getting far ahead of wall time.

--block-time values above 1s have correct intervals (e.g. timestamp increases by 2s per block with a --block-time of 2s), so this only seems to apply for values <1s.

Reproduction (observe how each block's timestamp goes up by 1s):

❯ anvil --block-time 0.01


                             _   _
                            (_) | |
      __ _   _ __   __   __  _  | |
     / _` | | '_ \  \ \ / / | | | |
    | (_| | | | | |  \ V /  | | | |
     \__,_| |_| |_|   \_/   |_| |_|

    0.2.0 (a470d63 2024-05-16T00:20:38.420768000Z)
    https://github.com/foundry-rs/foundry

Available Accounts
==================

(0) 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 (10000.000000000000000000 ETH)
(1) 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 (10000.000000000000000000 ETH)
(2) 0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC (10000.000000000000000000 ETH)
(3) 0x90F79bf6EB2c4f870365E785982E1f101E93b906 (10000.000000000000000000 ETH)
(4) 0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65 (10000.000000000000000000 ETH)
(5) 0x9965507D1a55bcC2695C58ba16FB37d819B0A4dc (10000.000000000000000000 ETH)
(6) 0x976EA74026E726554dB657fA54763abd0C3a0aa9 (10000.000000000000000000 ETH)
(7) 0x14dC79964da2C08b23698B3D3cc7Ca32193d9955 (10000.000000000000000000 ETH)
(8) 0x23618e81E3f5cdF7f54C3d65f7FBc0aBf5B21E8f (10000.000000000000000000 ETH)
(9) 0xa0Ee7A142d267C1f36714E4a8F75612F20a79720 (10000.000000000000000000 ETH)

Private Keys
==================

(0) 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80
(1) 0x59c6995e998f97a5a0044966f0945389dc9e86dae88c7a8412f4603b6b78690d
(2) 0x5de4111afa1a4b94908f83103eb1f1706367c2e68ca870fc3fb9a804cdab365a
(3) 0x7c852118294e51e653712a81e05800f419141751be58f605c371e15141b007a6
(4) 0x47e179ec197488593b187f80a00eb0da91f1b9d0b13f8733639f19c30a34926a
(5) 0x8b3a350cf5c34c9194ca85829a2df0ec3153be0318b5e2d3348e872092edffba
(6) 0x92db14e403b83dfe3df233f83dfa3a0d7096f21ca9b0d6d6b8d88b2b4ec1564e
(7) 0x4bbbf85ce3377467afe5d46f804f221813b2bb87f24d81f60f1fcdbf7cbf4356
(8) 0xdbda1821b80551c9d65939329250298aa3472ba22feea921c0cf5d620ea67b97
(9) 0x2a871d0798f97d79848a013d4936a73bf4cc922c825d33c1cf7073dff6d409c6

Wallet
==================
Mnemonic:          test test test test test test test test test test test junk
Derivation path:   m/44'/60'/0'/0/


Chain ID
==================

31337

Base Fee
==================

1000000000

Gas Limit
==================

30000000

Genesis Timestamp
==================

1715840211

Listening on 127.0.0.1:8545

    Block Number: 1
    Block Hash: 0xeca56a8d107e852363ae8a7751d130679266e24fb30a21794a925daaea376046
    Block Time: "Thu, 16 May 2024 06:16:52 +0000"


    Block Number: 2
    Block Hash: 0xc9cb337b3198b2f63c1fc4ada6a207aaae811a0ac83c6a43c7f304ac87b557dd
    Block Time: "Thu, 16 May 2024 06:16:53 +0000"


    Block Number: 3
    Block Hash: 0x12b492dfc7c20e63833bb9f64fb909a3b4b408d5fad23e8064aa5f746c504c2a
    Block Time: "Thu, 16 May 2024 06:16:54 +0000"


    Block Number: 4
    Block Hash: 0x7ba48879310c22b84b35b4380a533d051520ad340dc6765a686078cfbf4d39f1
    Block Time: "Thu, 16 May 2024 06:16:55 +0000"


    Block Number: 5
    Block Hash: 0xb7220b28fd063ae0460171a65640c72bbfbad0b235e8f3e471ae6f00244a4d72
    Block Time: "Thu, 16 May 2024 06:16:56 +0000"


    Block Number: 6
    Block Hash: 0x70c99f01c7dde1beb7c4475eb1cbd3e984483d85f021792745d6f39ee526d4de
    Block Time: "Thu, 16 May 2024 06:16:57 +0000"


    Block Number: 7
    Block Hash: 0x5ca657878d91937e18632af0ae4e62581a11056d172436b53f6fcd7eae54cfc3
    Block Time: "Thu, 16 May 2024 06:16:58 +0000"


    Block Number: 8
    Block Hash: 0xba03a9b70e155eacd1ea5c47aa36a7b1e76ebb2a0aa17b9992002060c3bc4fee
    Block Time: "Thu, 16 May 2024 06:16:59 +0000"


    Block Number: 9
    Block Hash: 0xce23210057796ae9225315016b68a2604d1d439cdd1820a67369af2304b64cb2
    Block Time: "Thu, 16 May 2024 06:17:00 +0000"

[transmissions11]

I guess the fix here might be non-trivial (or even wontfix), as block.timestamp is an integer ofc. I was imagining anvil maintain a separate internal "true" timestamp (lets call it true_timestamp) stored with decimals, and incrementing block.timestamp only when floor(true_timestamp) increases.

[mattsse]

yeah, I believe this breaks assumptions that timestamp always increases by at least one, but I can see how this could be useful and we can technically do it because we don't validate the timestamp.

@yash-atreya we can support float parsing and see what else we'd need to change in the time manager to support <1s intervals

[transmissions11]

right that's fair — up to you guys if you think it'd be okay to implement! fwiw if this does end up getting implemented, ideally the change would carry over to auto mining as well (as rn if you automine 100 blocks within 1s, block timestamp gets ahead of wall time by ~100s) — though as i say this i realize how confusing this could get... 😅 (maybe put this behavior behind a flag?)