You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 has
`env.block_number() - 1` because 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.
---------
Co-authored-by: benesjan <janbenes1234@gmail.com>
The `block_number` function from `TestEnvironment` has been expanded upon with two extra functions, the first being `pending_block_number`, and the second being `committed_block_number`. `pending_block_number` now returns what `block_number` does. In other words, it returns the block number of the block we are currently building. `committed_block_number` returns the block number of the last committed block, i.e. the block number that gets used to execute the private part of transactions when your PXE is successfully synced to the tip of the chain.
The `compute_nullifier_without_context` function from `NoteHash` (ex `NoteInterface`) is now called `compute_nullifier_unconstrained`, and instead of taking storage slot, contract address and nonce it takes a note hash for nullification (same as `compute_note_hash`). This makes writing this
0 commit comments