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(PXE): Querying contract private information from an app #2806

Open
Tracked by #5070
spalladino opened this issue Oct 11, 2023 · 3 comments
Open
Tracked by #5070

feat(PXE): Querying contract private information from an app #2806

spalladino opened this issue Oct 11, 2023 · 3 comments
Labels
S-needs-discussion Status: Still needs more discussion before work can start. T-feedback Type: recording user feedback

Comments

@spalladino
Copy link
Collaborator

What's the best approach for querying private infromation from a contract? There are two main approaches: using getPrivateStorageAt vs calling an unconstrained function.

Calling an unconstrained function seems like the best option, since it allows the contract dev to encapsulate logic to manipulate the notes before returning them. It also gets the storage layout and note deserialization logic from the contract, without having to reimplement all these in the app client code.

However, unconstrained functions are inherently slower than reading storage directly. And get_notes returns a maximum of 10 elements at a time, which makes sense when having to create a proof, but we could extend that limit when working unconstrained, so devs don't need to build pagination in on every getter.

We could make storage definitions declarative, so they can be exported in the ABI, and have a standard way for serialising notes, so given their struct definition we can have the client code automatically deserialize them. This way, just with the ABI, an app could grab any set of notes on any storage slot.

Alternatively, we should make it easier to write getters that handle pagination, and allow constrained functions to be used as getters as well to remove code duplication (see #2665).

Raised by @0xShaito from Wonderland in Discord

@spalladino spalladino added S-needs-discussion Status: Still needs more discussion before work can start. T-feedback Type: recording user feedback labels Oct 11, 2023
@github-project-automation github-project-automation bot moved this to Todo in A3 Oct 11, 2023
@spalladino
Copy link
Collaborator Author

We could make storage definitions declarative, so they can be exported in the ABI, and have a standard way for serialising notes, so given their struct definition we can have the client code automatically deserialize them. This way, just with the ABI, an app could grab any set of notes on any storage slot.

Thinking more about this, I believe that going through functions in the contract is nicer than reading private storage directly, since it lets the contract developer control what info is revealed to an app.

In my mind, when a dapp wants to read your private state from a contract, it'd ask your wallet, and the wallet would ask you if you grant permission to the dapp. If we grant permission for calling view functions but not reading storage directly, a smart contract dev can for instance show the total balance of a user in a token contract, but not reveal to the dapp what is the note composition (which a not-privacy-friendly dapp frontend could use for tracking the user activity).

@rahul-kothari
Copy link
Contributor

To confirm, there are two tasks here:

  • making storage declarative -> I believe @LeilaWang 's team will be looking into this (since they are already making huge changes to storage syntax etc and have worked on the ABI before)
  • handling pagination on Noir API for fetching notes -> @LHerskind's team

@LHerskind
Copy link
Contributor

Likely useful to have the storage layout from #5079.

@LHerskind LHerskind changed the title Querying contract private information from an app feat(PXE): Querying contract private information from an app Mar 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-needs-discussion Status: Still needs more discussion before work can start. T-feedback Type: recording user feedback
Projects
Status: Todo
Development

No branches or pull requests

3 participants