Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improvements in MockStoreSuccessBuilder #253

Merged
merged 4 commits into from
Mar 1, 2024
Merged

Conversation

polydez
Copy link
Contributor

@polydez polydez commented Feb 29, 2024

  • MockStoreSuccessBuilder and build_expected_block_header() now compute produced notes root
  • MockStoreSuccessBuilder::new() was replaced with two constructors: from_batches and from_accounts which allow it to fill initial account IDs and state and also nullifiers and produced notes.

This will resolve #79

@polydez polydez requested review from plafer and bobbinth February 29, 2024 12:04
@polydez polydez self-assigned this Mar 1, 2024
@@ -224,7 +224,7 @@ impl BlockProver {
let proof_hash = Digest::default();
let timestamp: Felt = SystemTime::now()
.duration_since(UNIX_EPOCH)
.expect("today is expected to be before 1970")
.expect("today is expected to be after 1970")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point

Comment on lines 45 to 50
let produced_nullifiers = batches
.iter()
.cloned()
.flat_map(TransactionBatch::produced_nullifiers)
.map(|nullifier| nullifier.inner())
.collect();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be removed, and fixes the test (as you mentioned offline).

The problem is that you're initializing the store with the "new" nullifiers that the transaction wants to update. That is, when a batch produces nullifiers (i.e. sets their value to [block_num, 0, 0, 0] in the store), they should have a value of [0, 0, 0, 0] in the store. Thus, in this function, we should not take the produced nullifiers and add them to the store - the block kernel will be doing that.

The error BlockProverFailed(ProgramExecutionFailed(MerkleStoreLookupFailed(RootNotInStore(...)))) is doesn't give much insight into why this fails (maybe we can fix that). When we initialize the Merkle store from the block witness, we basically assume that the value is 0 in the store (here). But since you set the value to something else here, the Merkle store root becomes inconsistent with the actual store's root (due to the fact that 2 nullifiers are set in the Merkle store, and not set in the actual store). So when we try to smt::set the new nullifier here, we provide the incorrect Merkle store root, which the VM complains about.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That was my main concern! Thank you! I've fixed this and CI is expected to pass now. Please, make a review if you have a chance!

Copy link
Contributor

@plafer plafer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@polydez polydez merged commit ba25321 into main Mar 1, 2024
4 checks passed
@polydez polydez deleted the polydez-created-notes-root branch March 1, 2024 14:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

block_builder tests: fix and use new infrastructure
2 participants