search

near / near-workspaces-js

Write tests once, run them both on NEAR TestNet and a controlled NEAR Sandbox local environment
https://near.github.io/near-workspaces-js/
GNU General Public License v3.0
42 stars 22 forks source link

Support time-travel / fast-forwarding #1

Open chadoh opened 3 years ago

chadoh commented 3 years ago

Give tests an interface to jump forward N blocks

willemneal commented 3 years ago

@ailisp Is this currently possible with the patch state method?

ailisp commented 3 years ago

@willemneal no, patch state is applied per block like transactions, it cannot instruct to produce several blocks at once. The time travel. @chadoh To be more clear, time travel and fast forwarding are two things. Time travel means to change the next block's timestamp, for example, three days after. Fast forwarding is produce N blocks at once so next block height is N more than current block. We have a mostly working time-travel implementation: https://github.com/near/nearcore/pull/3661, but some tests are not fixed to land it. As for fast forwarding, we didn't plan for it on nearcore/sandbox. I'll take over the time travel PR and also the fast forwarding feature on nearcore side recently

ailisp commented 3 years ago

@chadoh I realized what described in this issue is "fast-forwarding", and fast-forwarding is easier to implement so I'll work on it first. Arbitrary time travel, if needed, I suggest address in a later issue

willemneal commented 3 years ago

@ailisp We just need fast-forwarding for now. I'm definitely down to help with that once you get started!

ailisp commented 3 years ago

@willemneal Thanks for confirming! How soon will you need fast forwarding on nearcore side?

willemneal commented 3 years ago

@ailisp we just need it by the end of the quarter.

jberrytech commented 2 years ago

Blocker followup notes. Need core team support for this. Connecting with Bo to understand.

ailisp commented 2 years ago

I experimented with adversarial produce_blocks, and actually it has a different functionality than i expected: we'd like is quickly produce N blocks, that block k+1's parent block is block k. However, what adv_produce_blocks did is quickly produce N blocks, and each block height is ranging from N0+1,...N0+N, but each N0+k's parent block is all block N0. So a different mechanism need to implemented for fast forward.

Also, I found produce N blocks are pretty slow. It takes about 20s to produce 1000 empty blocks. This is limited by our chain's block calculation logics and unlikely to be faster. Is this sufficiently fast? Do we consider an alternative solution, where sandbox doesn't produce N blocks, it just produce one block at height N0+N and continue produce blocks as usual.

TrevorJTClarke commented 2 years ago

it just produce one block at height N0+N and continue produce blocks as usual.

Hello, just chiming in on the need (except over on workspaces-rs). Producing empty blocks seems like overkill, when it would be much more efficient to jump block height as suggested. It seems this would cause a major change to nearcore to be possible.

For reference, our use case needs fast forward because all core features are time based for cron.cat, where we are testing the scheduling of transactions gets executed after its supposed to.

ailisp commented 2 years ago

@TrevorJTClarke Yes I agree jump block height is more efficient and what we should implement! And I'd say fast forward is quite fit your use case