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

feat(FPI): Make storage maps usable by querying the node #645

Open
wants to merge 1 commit into
base: next
Choose a base branch
from

Conversation

igamigo
Copy link
Collaborator

@igamigo igamigo commented Dec 22, 2024

Implements changes following up 0xPolygonMiden/miden-node#598 in order to allow using storage maps on FPI.
This was a feature requested by pioneers.

@igamigo igamigo marked this pull request as ready for review December 27, 2024 20:41
@igamigo igamigo changed the title feat: Make storage maps usable on FPI feat(FPI): Make storage maps usable by querying the node Dec 30, 2024
Copy link
Collaborator

@tomyrd tomyrd 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, left some minor comments/questions.

@@ -181,7 +184,22 @@ impl ProtoAccountStateHeader {
}
};

Ok(StateHeaders { account_header, storage_header, code })
// Get map values into slot |-> (key, value, proof) mapping
Copy link
Collaborator

Choose a reason for hiding this comment

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

I would change this to:

Suggested change
// Get map values into slot |-> (key, value, proof) mapping
// Get map values into slot |-> [proof0, proof1, ...] mapping

As I don't think we are storing the keys and values here.

@@ -217,7 +236,10 @@ impl AccountProof {
account_hash: Digest,
state_headers: Option<StateHeaders>,
) -> Result<Self, AccountProofError> {
if let Some(StateHeaders { account_header, storage_header: _, code }) = &state_headers {
if let Some(StateHeaders {
account_header, storage_header: _, code, ..
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think this could work too:

Suggested change
account_header, storage_header: _, code, ..
account_header, code, ..

}

let headers = if include_headers && account_id.is_public() {
// Because we set `include_headers` to true, for any public account we requeted we
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
// Because we set `include_headers` to true, for any public account we requeted we
// Because we set `include_headers` to true, for any public account we requested we

///
/// At execution, the client queries the node and retrieves account-related data, based on
/// what's defined in `foreign_accounts`
pub fn with_foreign_accounts(
Copy link
Collaborator

Choose a reason for hiding this comment

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

We could end up with duplicate accounts when using with_foreign_accounts/with_public_foreign_accounts/with_private_foreign_accounts. Maybe we could do a duplicate check when inserting or store them in a BTreeMap/Set. Plus, do we need all 3 methods? Maybe we could have just the first one, the creation of the ForeignAccount items would need to be done by the caller.

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.

2 participants