starknet_committer: derive skeleton updates from actual updates

[yoavGrs]

read_original_forest now takes &Input. The skeleton updates fed to
UpdatedSkeletonForest are derived from the already-computed actual
updates via a generic skeleton_trie_updates (pure value mapping),
instead of re-walking the state diff. Adds From<_> for SkeletonLeaf
impls for the leaf value types to back the generic bound.

Co-Authored-By: Claude Opus 4.7 (1M context) noreply@anthropic.com

[yoavGrs]

• starknet_committer: name TrieReadTask lifetimes and document them #14239
• starknet_committer: derive skeleton updates from actual updates #14214 👈 (View in Graphite)
• starknet_committer: split commit_block into read and compute phases #14213
• main

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

[reviewable-StarkWare]

This change is 

[cursor]

PR Summary

Medium Risk
Touches the block commitment compute path where skeleton vs actual updates must stay aligned; logic is a refactor but incorrect mapping would change trie topology.

Overview
Skeleton trie inputs for forest updates are now derived from the already-computed actual leaf modifications instead of being rebuilt by walking StateDiff again.

compute_updated_forest passes skeleton_trie_updates / skeleton_storage_updates built from actual_classes_updates and actual_storage_updates, and only threads address_to_class_hash and address_to_nonce where contract metadata is still needed. The old StateDiff::skeleton_* helpers are removed in favor of a generic skeleton_trie_updates mapper plus From conversions on StarknetStorageValue and CompiledClassHash into SkeletonLeaf (zero vs non-zero).

^{Reviewed by Cursor Bugbot for commit 058f53b. Bugbot is set up for automated code reviews on this repo. Configure here.}

[dorimedini-starkware]

@dorimedini-starkware reviewed 1 file and all commit messages, and made 1 comment.
Reviewable status: 1 of 3 files reviewed, 1 unresolved discussion (waiting on ArielElp and yoavGrs).

---

crates/starknet_committer/src/block_committer/commit.rs line 128 at r1 (raw file):

    actual_storage_updates: HashMap<ContractAddress, LeafModifications<StarknetStorageValue>>,
    actual_classes_updates: LeafModifications<CompiledClassHash>,
    state_diff: &StateDiff,

previously the relevant modifications were read directly from the state_diff, but now you use the actual updates.
Can you prove it's equivalent?

Code quote:

    actual_storage_updates: HashMap<ContractAddress, LeafModifications<StarknetStorageValue>>,
    actual_classes_updates: LeafModifications<CompiledClassHash>,
    state_diff: &StateDiff,

[yoavGrs]

@yoavGrs made 1 comment.
Reviewable status: 1 of 3 files reviewed, 1 unresolved discussion (waiting on ArielElp and dorimedini-starkware).

---

crates/starknet_committer/src/block_committer/commit.rs line 128 at r1 (raw file):

Previously, dorimedini-starkware wrote…

previously the relevant modifications were read directly from the state_diff, but now you use the actual updates.
Can you prove it's equivalent?

If I understand your question:
Look at the previous version of skeleton_storage_updates and actual_storage_updates. They collect entries using the same logic but map them to different types.
The same claim for skeleton_classes_updates and actual_classes_updates.

[dorimedini-starkware]

@dorimedini-starkware made 1 comment.
Reviewable status: 1 of 3 files reviewed, 1 unresolved discussion (waiting on ArielElp and yoavGrs).

---

crates/starknet_committer/src/block_committer/commit.rs line 128 at r1 (raw file):

Previously, yoavGrs wrote…

If I understand your question:
Look at the previous version of skeleton_storage_updates and actual_storage_updates. They collect entries using the same logic but map them to different types.
The same claim for skeleton_classes_updates and actual_classes_updates.

state_diff.skeleton_storage_updates() would iterated over state_diff.accessed_addresses() for the address keys, and then map state_diff.storage_updates[address] to the skeleton nodes. you are saying this is the same as mapping actual_storage_updates to skeleton nodes? how can I see it?

[yoavGrs]

@yoavGrs made 1 comment.
Reviewable status: 1 of 3 files reviewed, 1 unresolved discussion (waiting on ArielElp and dorimedini-starkware).

---

crates/starknet_committer/src/block_committer/commit.rs line 128 at r1 (raw file):

Previously, dorimedini-starkware wrote…

state_diff.skeleton_storage_updates() would iterated over state_diff.accessed_addresses() for the address keys, and then map state_diff.storage_updates[address] to the skeleton nodes. you are saying this is the same as mapping actual_storage_updates to skeleton nodes? how can I see it?

Look at the way that actual_storage_updates is created - iterating over state_diff.accessed_addresses() for the address keys, and then mapping state_diff.storage_updates[address] to storage updates.

[dorimedini-starkware]

@dorimedini-starkware reviewed 2 files, made 2 comments, and resolved 1 discussion.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on ArielElp and yoavGrs).

---

crates/starknet_committer/src/block_committer/commit.rs line 128 at r1 (raw file):

Previously, yoavGrs wrote…

Look at the way that actual_storage_updates is created - iterating over state_diff.accessed_addresses() for the address keys, and then mapping state_diff.storage_updates[address] to storage updates.

ah. in that case, see below

---

crates/starknet_committer/src/block_committer/commit.rs line 167 at r1 (raw file):

}

/// Compares the previous state's nonce and class hash with the given in the state diff.

passing both a state diff AND input that is derived from state diff is not optimal

Suggestion:

/// Computes the updated forest topology, its new hashes, and the nodes deleted by the state diff.
async fn compute_updated_forest<M: MeasurementsTrait + Send>(
    original_forest: OriginalSkeletonForest<'_>,
    original_contracts_trie_leaves: HashMap<NodeIndex, ContractState>,
    actual_storage_updates: HashMap<ContractAddress, LeafModifications<StarknetStorageValue>>,
    actual_classes_updates: LeafModifications<CompiledClassHash>,
    address_to_class_hash: &HashMap<ContractAddress, ClassHash>,
    address_to_nonce: &HashMap<ContractAddress, Nonce>,
    measurements: &mut M,
) -> BlockCommitmentResult<(FilledForest, DeletedNodes)> {
    measurements.start_measurement(Action::Compute);

    // Compute the new topology.
    let updated_forest = UpdatedSkeletonForest::create(
        &original_forest,
        &state_diff.skeleton_classes_updates(),
        &state_diff.skeleton_storage_updates(),
        &original_contracts_trie_leaves,
        address_to_class_hash,
        address_to_nonce,
    )?;
    debug!("Updated skeleton forest created successfully.");

    // Find deleted nodes.
    let deleted_nodes = find_deleted_nodes(
        &original_forest,
        &updated_forest,
        &actual_storage_updates,
        &actual_classes_updates,
        &original_contracts_trie_leaves,
    );

    // Compute the new hashes.
    let filled_forest = FilledForest::create::<TreeHashFunctionImpl>(
        updated_forest,
        actual_storage_updates,
        actual_classes_updates,
        &original_contracts_trie_leaves,
        address_to_class_hash,
        address_to_nonce,
    )
    .await?;
    measurements.attempt_to_stop_measurement(Action::Compute, 0).ok();
    debug!("Filled forest created successfully.");

    Ok((filled_forest, deleted_nodes))
}

[yoavGrs]

@yoavGrs made 1 comment.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on ArielElp and dorimedini-starkware).

---

crates/starknet_committer/src/block_committer/commit.rs line 167 at r1 (raw file):

Previously, dorimedini-starkware wrote…

passing both a state diff AND input that is derived from state diff is not optimal

Done.
It would be nice if actual_storage_updates borrowed the state diff, but not now.

[dorimedini-starkware]

@dorimedini-starkware reviewed 1 file and all commit messages, and resolved 1 discussion.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on ArielElp).

[ArielElp]

@ArielElp reviewed 3 files and all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on yoavGrs).

[dorimedini-starkware]

@dorimedini-starkware reviewed 6 files and all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on yoavGrs).

[graphite-app]

Merge activity

• May 28, 12:53 PM UTC: Graphite rebased this pull request, because this pull request is set to merge when ready.

[dorimedini-starkware]

Reviewable status: complete! all files reviewed, all discussions resolved (waiting on yoavGrs).