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

Return richer information on SyncSummary #512

Closed
igamigo opened this issue Sep 2, 2024 · 4 comments
Closed

Return richer information on SyncSummary #512

igamigo opened this issue Sep 2, 2024 · 4 comments
Assignees
Milestone

Comments

@igamigo
Copy link
Collaborator

igamigo commented Sep 2, 2024

What should be done?

Currently, we are just returning basic flat stats on SyncSummary such as number of new notes, number of committed transactions, etc. We could improve this and return IDs of each of the involved entities.

How should it be done?

Gather IDs of new entities and return them in Vec<_> fields. The struct should look something like:

pub struct SyncSummary {
    pub block_num: u32,
    pub new_notes: Vec<NoteId>,
    pub new_inclusion_proofs: Vec<NoteId>,
    pub new_nullifiers: Vec<Nullifier>, // maybe NoteId instead?
    pub updated_onchain_accounts: Vec<AccountId>, 
    pub commited_transactions: Vec<TransactionId>,
}

When is this task done?

When we return richer information on SyncSummary as described above. The CLI can keep its current functionality by showing the count of each of these fields.

Additional context

No response

@bobbinth
Copy link
Contributor

bobbinth commented Sep 2, 2024

We may also consider the following structure:

pub struct SyncSummary {
    pub block_num: u32,
    pub received_notes: Vec<NoteId>,
    pub committed_notes: Vec<NoteId>,
    pub consumed_notes: Vec<NoteId>,
    pub updated_accounts: Vec<AccountId>, 
    pub committed_transactions: Vec<TransactionId>,
}

@tomyrd
Copy link
Collaborator

tomyrd commented Sep 4, 2024

Just to be clear, the change from new_nullifiers: Vec<Nullifier> to consumed_notes: Vec<NoteId> would mean a separate query to retrieve the consumed note ids (currently we only update the notes that match the nullifiers without returning the ids). This wouldn't be a problem no?

@bobbinth
Copy link
Contributor

bobbinth commented Sep 4, 2024

Just to be clear, the change from new_nullifiers: Vec<Nullifier> to consumed_notes: Vec<NoteId> would mean a separate query to retrieve the consumed note ids (currently we only update the notes that match the nullifiers without returning the ids). This wouldn't be a problem no?

I think this may be OK. With the refactoring we are discussing in #487 I think we'll be retrieving all relevant notes from the store anyways, then applying state transitions to them, and then saving them back to the store. So, the amount of work probably wouldn't be that different.

@bobbinth bobbinth added this to the v0.6.0 milestone Sep 8, 2024
@tomyrd
Copy link
Collaborator

tomyrd commented Sep 16, 2024

Closed by #513

@tomyrd tomyrd closed this as completed Sep 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

No branches or pull requests

3 participants