fix: make block number in txe make sense #11807
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
sklppy88
force-pushed
the
ek/fix/make-block-number-in-txe-make-sense
branch
2 times, most recently
from
3bb2506 to
57bee7d
Compare
| @@ -54,7 +54,7 @@ unconstrained fn test_get_scheduled_value_in_public() { | |||
|
|
|||
| let (scheduled, block_of_change) = state_var.get_scheduled_value(); | |||
| assert_eq(scheduled, new_value); | |||
| assert_eq(block_of_change, env.block_number() + TEST_INITIAL_DELAY); | |||
| assert_eq(block_of_change, env.block_number() + 1 + TEST_INITIAL_DELAY); | |||
There was a problem hiding this comment.
Because now env.block_number() to the most recent committed block, the initial delay needs to be added the block that this tx will be committed in (which is env.block_number() + 1.
There was a problem hiding this comment.
Nobody reading the test would have any clue why this is the case. We need better naming here.
| @@ -120,7 +120,7 @@ unconstrained fn test_get_scheduled_delay_in_public() { | |||
| let (scheduled, block_of_change) = state_var.get_scheduled_delay(); | |||
| assert_eq(scheduled, new_delay); | |||
| // The new delay is smaller, therefore we need to wait for the difference between current and new | |||
| assert_eq(block_of_change, env.block_number() + TEST_INITIAL_DELAY - new_delay); | |||
| assert_eq(block_of_change, env.block_number() + 1 + TEST_INITIAL_DELAY - new_delay); | |||
sklppy88
force-pushed
the
ek/fix/make-block-number-in-txe-make-sense
branch
3 times, most recently
from
35cc0c4 to
cd72a0e
Compare
sklppy88
force-pushed
the
ek/fix/make-block-number-in-txe-make-sense
branch
from
cd72a0e to
69c913c
Compare
| @@ -22,7 +22,7 @@ impl TestEnvironment { | |||
| } | |||
|
|
|||
| pub unconstrained fn block_number(_self: Self) -> u32 { | |||
| get_block_number() | |||
| get_block_number() - 1 | |||
There was a problem hiding this comment.
This function needs to be documented. It's also just weird that we have a env.block_number() function and it returns different thing from get_block_number() oracle.
I think we should rename TestEnvironment::block_number to TestEnvironment::committed_block_number or smt. Or alternatively to historical_block_number since we call it like that here.
Also do you know what block number would be used in private calls and what be used in public calls? Would it be the case that in private we would have output of env.block_number() and in public it would be incremented by 1?
| @@ -54,7 +54,7 @@ unconstrained fn test_get_scheduled_value_in_public() { | |||
|
|
|||
| let (scheduled, block_of_change) = state_var.get_scheduled_value(); | |||
| assert_eq(scheduled, new_value); | |||
| assert_eq(block_of_change, env.block_number() + TEST_INITIAL_DELAY); | |||
| assert_eq(block_of_change, env.block_number() + 1 + TEST_INITIAL_DELAY); | |||
There was a problem hiding this comment.
Nobody reading the test would have any clue why this is the case. We need better naming here.
Right now
env.block_number()returns the block number that is currently being built, as per an arbitrary choice when creating the TXe.But this has a strange side effect of the current block (from the header) and
env.block_number()not matching up. The current header hasenv.block_number() - 1because the current header reflects the state of the last committed block.Before this mattered less because we couldn't do historical proofs, and because we had less of a notion of "correctness" in blocks but now due to the changes this makes sense to change.