blockifier: add estimate_casm_blake_hash_computation_resources

[avivg-starkware]

No description provided.

[reviewable-StarkWare]

This change is 

[github-actions]

Artifacts upload workflows:

• Started at 2025-06-11T20:00:00Z
• Started at 2025-06-12T13:49:30Z
• Started at 2025-06-12T14:01:31Z
• Started at 2025-06-12T14:18:38Z
• Started at 2025-06-12T15:07:30Z
• Started at 2025-07-01T15:56:21Z
• Started at 2025-07-01T15:59:22Z
• Started at 2025-07-01T16:34:39Z
• Started at 2025-07-02T07:41:14Z
• Started at 2025-07-02T07:49:03Z
• Started at 2025-07-02T10:03:08Z
• Started at 2025-07-06T09:09:15Z
• Started at 2025-07-06T09:09:15Z
• Started at 2025-07-06T13:12:45Z
• Started at 2025-07-06T13:17:28Z
• Started at 2025-07-06T13:17:28Z
• Started at 2025-07-06T13:25:17Z
• Started at 2025-07-06T13:25:59Z
• Started at 2025-07-08T11:44:59Z
• Started at 2025-07-08T11:44:59Z
• Started at 2025-07-10T09:51:42Z
• Started at 2025-07-10T10:09:59Z
• Started at 2025-07-10T10:25:25Z

[avivg-starkware]

• blockifier: add estimate_casm_blake_hash_computation_resources #7212 👈 (View in Graphite)
• blockifier: add fn encode_felt252_data_and_calc_blake_hash_cost #7147
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[meship-starkware]

Reviewed 1 of 2 files at r1, all commit messages.
Reviewable status: 1 of 2 files reviewed, 3 unresolved discussions (waiting on @noaov1)

---

crates/blockifier/src/execution/contract_class.rs line 363 at r1 (raw file):

    // Hash all (segment_hash, segment_length) pairs.
    resources += &cost_of_encode_felt252_data_and_calc_blake_hash(segs.len(), segs.len());

How do we know that n_small_felts = n_big_felts = segs.len()?

Code quote:

resources += &cost_of_encode_felt252_data_and_calc_blake_hash(segs.len(), segs.len());

---

crates/blockifier/src/execution/contract_class.rs line 379 at r1 (raw file):

                resources += &leaf_cost(*len);
            }
            _ => panic!("Estimating hash cost only supports at most one level of segmentation."),

Why? Does this mean we can only have leaves or a list of leaves?

Suggestion:

_ => panic!("Estimating hash cost only supports at most one level of segmentation."),       

---

crates/blockifier/src/execution/contract_class.rs line 389 at r1 (raw file):

/// - TODO(AvivG): Currently ignores entry-point costs.
/// - Uses only bytecode size (treats all felts as “big”, ignores the small-felt optimization).
/// - This estimation was done by...

Is this comment supposed to be completed?

Code quote:

/// - This estimation was done by...

[avivg-starkware]

Reviewable status: 1 of 2 files reviewed, 3 unresolved discussions (waiting on @meship-starkware and @noaov1)

---

crates/blockifier/src/execution/contract_class.rs line 363 at r1 (raw file):

Previously, meship-starkware (Meshi Peled) wrote…

How do we know that n_small_felts = n_big_felts = segs.len()?

for each node, another "segment" that is being hashed is the sequence of felts containing all it's inner segments hashes and their lengths. hash=>"big" felt , length=>"small" felt

---

crates/blockifier/src/execution/contract_class.rs line 379 at r1 (raw file):

Previously, meship-starkware (Meshi Peled) wrote…

Why? Does this mean we can only have leaves or a list of leaves?

Yes, exactly, this is the current logic in the OS as well. You can see that this structure was copied from the original function estimate_casm_poseidon_hash_computation_resources

And I'm happy to elaborate verbally if you'd like

---

crates/blockifier/src/execution/contract_class.rs line 389 at r1 (raw file):

Previously, meship-starkware (Meshi Peled) wrote…

Is this comment supposed to be completed?

As the process is not complete, I wasn't sure what to write (but thought it might be helpful for the reader), removed for now

[meship-starkware]

Reviewed 1 of 2 files at r2, all commit messages.
Reviewable status: 1 of 2 files reviewed, 3 unresolved discussions (waiting on @noaov1)

[meship-starkware]

Reviewed all commit messages.
Reviewable status: 0 of 2 files reviewed, all discussions resolved (waiting on @noaov1)

[meship-starkware]

Reviewed 1 of 2 files at r4.
Reviewable status: 1 of 2 files reviewed, 2 unresolved discussions (waiting on @noaov1)

---

crates/blockifier/src/execution/contract_class.rs line 388 at r5 (raw file):

    let segment_overhead = GasAmount::ZERO;

    // 2) For each segment, hash its felts.

Why 2) should there be 1? I'm also not sure I understand the meaning of this comment

Suggestion:

// For each segment, hash its feel.

---

crates/blockifier/src/execution/contract_class.rs line 403 at r5 (raw file):

    let node_hash_cost = cost_of_encode_felt252_data_and_calc_blake_hash(
        segs.len(),
        segs.len(),

This is an estimation of the worst case, right? If I understand correctly, n_small_felts + n_big_felts = segs.len()
Is there a way to give a stricter bound? Anyway, this is outside of this PR's scope

Code quote:

        segs.len(),
        segs.len(),

[meship-starkware]

Reviewed 1 of 1 files at r5.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @avivg-starkware and @noaov1)

---

crates/blockifier/src/execution/contract_class.rs line 426 at r5 (raw file):

        n_memory_holes: 0,
        builtin_instance_counter: HashMap::from([(BuiltinName::range_check, 3)]),
    };

Out of curiosity, where did these numbers come from?

Code quote:

    let resources = ExecutionResources {
        n_steps: 0,
        n_memory_holes: 0,
        builtin_instance_counter: HashMap::from([(BuiltinName::range_check, 3)]),
    };

[meship-starkware]

Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @avivg-starkware and @noaov1)

---

crates/blockifier/src/execution/contract_class.rs line 388 at r5 (raw file):

Previously, meship-starkware (Meshi Peled) wrote…

Why 2) should there be 1? I'm also not sure I understand the meaning of this comment

// For each segment, hash its felts. Sorry auto corrector

[avivg-starkware]

Reviewable status: 1 of 2 files reviewed, 2 unresolved discussions (waiting on @meship-starkware and @noaov1)

---

crates/blockifier/src/execution/contract_class.rs line 403 at r5 (raw file):

Previously, meship-starkware (Meshi Peled) wrote…

This is an estimation of the worst case, right? If I understand correctly, n_small_felts + n_big_felts = segs.len()
Is there a way to give a stricter bound? Anyway, this is outside of this PR's scope

Actually, this is an exact estimation :)
We hash both the hash and the length of each inner segment — that is, one big felt (the hash) and one small felt (the length) per segment. So for segs.len() segments, we’re hashing exactly segs.len() big felts and segs.len() small felts.
That’s why passing segs.len(), segs.len() here reflects the exact number of big and small felts involved.

[avivg-starkware]

Reviewable status: 1 of 2 files reviewed, 2 unresolved discussions (waiting on @meship-starkware and @noaov1)

---

crates/blockifier/src/execution/contract_class.rs line 426 at r5 (raw file):

Previously, meship-starkware (Meshi Peled) wrote…

Out of curiosity, where did these numbers come from?

The value 3 is based on observed behavior from manually running the computation.

I changed the TODOs , to revisit this when compiled_class_hash estimation is complete

[meship-starkware]

Reviewable status: 1 of 2 files reviewed, all discussions resolved (waiting on @noaov1)

---

crates/blockifier/src/execution/contract_class.rs line 403 at r5 (raw file):

Previously, avivg-starkware wrote…

Actually, this is an exact estimation :)
We hash both the hash and the length of each inner segment — that is, one big felt (the hash) and one small felt (the length) per segment. So for segs.len() segments, we’re hashing exactly segs.len() big felts and segs.len() small felts.
That’s why passing segs.len(), segs.len() here reflects the exact number of big and small felts involved.

I see that makes sense thanks for the explanetion :)

[meship-starkware]

Reviewed 1 of 1 files at r7, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @noaov1)