Skip to content

Conversation

@igamigo
Copy link
Collaborator

@igamigo igamigo commented Jan 9, 2026

Adds AccountSchemaCommitment component, which exposes a single storage slot (named miden::standards::metadata::storage_schema) and contains a commitment to the schema of the account, given by the hash of ordered the list of StorageSchema commitments - one per component - introduced in #2244.

A follow-up (#2269) was created for adding metadata to account component in a way that makes it easy to leverage on AccountBuilder.

@igamigo igamigo force-pushed the igamigo-schema-commit branch from abbe163 to 9aa118c Compare January 9, 2026 21:42
@igamigo igamigo marked this pull request as ready for review January 13, 2026 02:33
@mmagician mmagician requested a review from Copilot January 13, 2026 10:13
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull request overview

This PR introduces a new AccountSchemaCommitment component that enables accounts to expose their storage schema commitments on-chain. The component stores a cryptographic commitment to the account's storage schemas in a designated storage slot and provides a procedure to retrieve this commitment.

Changes:

  • Added new AccountSchemaCommitment component to compute and store deterministic storage schema commitments
  • Implemented schema commitment computation with lexicographic ordering for order-independence
  • Added MASM procedure get_schema_commitment to retrieve the schema commitment from account storage

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 8 comments.

Show a summary per file
File Description
crates/miden-standards/src/account/mod.rs Exports the new metadata module
crates/miden-standards/src/account/metadata/mod.rs Implements AccountSchemaCommitment component with schema commitment computation
crates/miden-standards/src/account/components/mod.rs Adds storage_schema_library() function to access the metadata library
crates/miden-standards/asm/account_components/metadata/storage_schema.masm Implements get_schema_commitment MASM procedure
CHANGELOG.md Documents the new feature

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@@ -0,0 +1,21 @@
# TODO: docs
Copy link

Copilot AI Jan 13, 2026

Choose a reason for hiding this comment

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

Missing documentation for this module. Add a header comment explaining the purpose of this module and the storage_schema component.

Suggested change
# TODO: docs
# METADATA STORAGE SCHEMA COMPONENT
# -------------------------------------------------------------------------------------------------
# This module defines the metadata storage_schema component for accounts. It exposes the storage
# slot at which an account stores a commitment to its storage schema, and provides a helper
# procedure to load that commitment from the active account's storage.
#
# The SCHEMA_COMMITMENT_SLOT constant identifies the word in the account's storage layout that
# contains the storage schema commitment. The get_schema_commitment procedure reads this slot
# via active_account::get_item and returns the stored commitment on the stack.

Copilot uses AI. Check for mistakes.
Copy link
Contributor

@mmagician mmagician left a comment

Choose a reason for hiding this comment

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

Whether for now or for another PR, TBD, but it would be useful to also have an option (perhaps default to true) to set AccountBuilder::with_schema(boolean) to indicate whether this component should be built automatically at the time of account creation.

As discussed here, it might be a little more tricky than originally envisioned because at the time when we'd call AccountBuilder::with_schema(boolean), I think we've lost the metadata already.

But, we should have some way (with account builder or otherwise) to conveniently create this component, otherwise I don't see much value in doing all the pre-requisite steps in #2104.

@igamigo
Copy link
Collaborator Author

igamigo commented Jan 13, 2026

As discussed here, it might be a little more tricky than originally envisioned because at the time when we'd call AccountBuilder::with_schema(boolean), I think we've lost the metadata already.

As I mentioned in the second paragraph of this comment, you are already working with components at that point, which do not have metadata associated directly (you might have gotten the component by building it yourself, without AccountComponentMetadata ever being involved or from something like a Package, but the metadata gets discarded before converting into an AccountComponent) . @bobbinth 's suggestion of adding the metadata to a component would be a way to enable this. In any case, I was thinking this helper functionality would not be the scope of this PR. I will draft another set of changes to test this approach.

@igamigo
Copy link
Collaborator Author

igamigo commented Jan 13, 2026

Created #2269 with a possible approach cc @mmagician, left a couple of caveats in the description

Copy link
Contributor

@bobbinth bobbinth left a comment

Choose a reason for hiding this comment

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

Looks good! Thank you! I left a couple of comments inline - the main one is about the methodology for combining schemas.

Comment on lines +71 to +86
fn compute_schema_commitment(schemas: &[StorageSchema]) -> Word {
if schemas.is_empty() {
return Word::empty();
}

let mut commitments: Vec<Word> = schemas.iter().map(StorageSchema::commitment).collect();
commitments.sort_by(|a, b| LexicographicWord::new(*a).cmp(&LexicographicWord::new(*b)));

let mut bytes = Vec::with_capacity(commitments.len() * Word::SERIALIZED_SIZE);
for commitment in commitments.iter() {
commitment.write_into(&mut bytes);
}

let elements = bytes_to_elements_with_padding(&bytes);
Hasher::hash_elements(&elements)
}
Copy link
Contributor

Choose a reason for hiding this comment

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

I was imagining this working slightly differently:

  1. We'd first merge schemas together into a single schema.
  2. Then, we'd compute a commitment to this schema.

The above approach would be a bit "semantically robust". And I think it shouldn't be too difficult to implement because we already have the ability to merge schemas?

Copy link
Contributor

Choose a reason for hiding this comment

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

I would move the code under asm/standards/metadata/storage_schema.masm and then this file would just re-export the procedure - e.g., as:

pub use ::miden::standards::metadata::storage_schema::get_schema_commitment

This is the approach we've been taking with account components recently.

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.

4 participants