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

Reexecute block / Pathfinder Integration continuation #306

Merged

Conversation

notlesh
Copy link
Collaborator

@notlesh notlesh commented Aug 9, 2024

This PR continues improving the prove_block binary. Specifically:

  • More data fetched through RPC
  • We now pass all OS txn executions on the block we've been focusing on (Sepolia block 76793)
  • Class hashing and compiled class hashing are consistent with OS
    • Including the starknet-core types used by Pathfinder
  • Class bytecode is properly loaded, including for contracts enountered during subcalls
    • (deprecated contracts still TODO)
  • Visited-PCs (and bytecode segmentation) supported

Issue Number: N/A

Type

  • feature
  • bugfix
  • dev (no functional changes, no API changes)
  • fmt (formatting, renaming)
  • build
  • docs
  • testing

Description

Breaking changes?

  • yes
  • no

odesenfans and others added 17 commits August 7, 2024 10:28
Problem: we need a way to reexecute blocks with Blockifier.

Solution: implement the `StateReader` trait using the `starknet-rs`
crate to fetch all the relevant data from a Pathfinder node.
Problem: the code needed to only partially load programs based on
visited PCs was left as a TODO. We were wondering if this code could be
the cause of some hashing issues.

Solution: implement bytecode segment loading properly. We should now
support visited PCs to a reasonable extent.
@notlesh notlesh changed the title Notlesh/reexecute blocks Reexecute block / Pathfinder Integration continuation Aug 9, 2024
odesenfans and others added 10 commits August 13, 2024 15:11
Problem: we are facing issues integrating the model of
`OsSingleStarknetStorage` with Pathfinder, as we do not have a method to
traverse the tree to reach arbitrary leaves.

Solution: Make the OS generic on the per-contract storage type instead
of just the storage. This allows users to further customize the
behaviour of the OS when it comes to storage.
@notlesh notlesh marked this pull request as ready for review August 14, 2024 17:58
@notlesh notlesh requested a review from odesenfans as a code owner August 14, 2024 17:58
crates/bin/prove_block/src/main.rs Outdated Show resolved Hide resolved
crates/bin/prove_block/src/main.rs Show resolved Hide resolved
crates/bin/prove_block/src/main.rs Show resolved Hide resolved
crates/bin/prove_block/src/main.rs Outdated Show resolved Hide resolved
crates/bin/prove_block/src/main.rs Outdated Show resolved Hide resolved
crates/bin/prove_block/src/main.rs Outdated Show resolved Hide resolved
}
} else {
log::warn!("No class hash available for contract {}", contract_address);
};
}

// query storage proofs for each accessed contract
Copy link
Collaborator

Choose a reason for hiding this comment

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

Its redundant, but add that you are query storage proofs for the class trie. (as difference as previous ones)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Do you mean that storage proofs should be class proofs?

Copy link
Collaborator

Choose a reason for hiding this comment

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

something like: query class trie storage proofs for each accessed contract

Comment on lines 474 to 492
let class_hashes: Vec<&Felt252> = class_hash_to_compiled_class_hash.keys().collect();
let class_proofs = get_class_proofs(&pathfinder_client, &args.rpc_provider, block_number, &class_hashes[..])
.await
.expect("Failed to fetch class proofs");

// write facts from class proof
for proof in class_proofs.values() {
for node in &proof.class_proof {
match node {
TrieNode::Binary { left, right } => {
// log::info!("writing binary node...");
let fact = BinaryNodeFact::new((*left).into(), (*right).into())?;
fact.set_fact(&mut initial_state.ffc_for_class_hash).await?;
}
TrieNode::Edge { child, path } => {
// log::info!("writing edge node...");
let fact = EdgeNodeFact::new((*child).into(), NodePath(path.value.to_biguint()), Length(path.len))?;
fact.set_fact(&mut initial_state.ffc_for_class_hash).await?;
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

Here we dont need the previous ones (as with contract proofs)?

Not necessary to add now, but im curious :)

If we need, lests make sure to add this in the ticket that refers to class data stuff

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

By previous are you referring to using block_number instead of block_number - 1?

That's a good catch, and probably something really subtle since the class isn't likely to change from block to block...

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Changed to block-1 here: Moonsong-Labs@3386814

That said, I wonder if we actually need both like we do with the storage proofs... @odesenfans WDYT?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Yup! But in the blocks that decalre stuff can happen! Maybe leave a comment or TODO just for us to be aware of this

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Oh, good point, that's a simple case where this would be relevant.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

})
.collect();

log::debug!("class_hash_to_compiled_class_hash ({}):", class_hash_to_compiled_class_hash.len());
for (ch, cch) in &class_hash_to_compiled_class_hash {
Copy link
Collaborator

Choose a reason for hiding this comment

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

put better names to this variables

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

let os_input = StarknetOsInput {
contract_state_commitment_info,
contract_state_commitment_info: Default::default(),
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why are you putting a default?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This isn't relevant until the end of the OS when we compute the state roots, which is coming $soon

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Also, see all the commented-out code above this -- it'll be implemented soon

* Move process_function_invocations() out of main()

* Remove debug logging

* Fail fast when txn has no sender_address

* Remove stale comment

* Use ffc_for_class_hash instead of clone_with_different_hash()

* Remove verbose class hash logging

* Query class proofs at previous block

* Not afraid of Carpal tunnel

* Add TODO about fetching classes at current block

* fmt
@notlesh notlesh merged commit c302dbe into keep-starknet-strange:main Aug 14, 2024
5 checks passed
@HermanObst HermanObst deleted the notlesh/reexecute-blocks branch August 18, 2024 16:48
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.

3 participants