-
Notifications
You must be signed in to change notification settings - Fork 47
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
refactor: forester: batch ops #1453
base: main
Are you sure you want to change the base?
Conversation
TreeType::BatchedState => { | ||
info!("Processing state batch"); | ||
state::process_batch(&self.context).await | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this needs to distinguish between an input(nullifier) queue batch being ready and an output queue batch being ready. The current implementation assumes that both are always ready at the same time which will fail in many cases.
} | ||
} | ||
|
||
async fn verify_batch_ready(&self) -> bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
doesn't cover the output queue whichs batches are independent of input queue batches.
The input queue is part of the Merkle tree account since we usually need access to Merkle tree roots to prove inclusion (except if the account hash wasn't inserted into the tree yet then we need the output queue to proof inclusion by index in the value array).
The output queue is a separate account with separate batches. You can check whether an output queue batch is ready with the same logic used for trees the data structure is similar.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The address Merkle tree doesn't have an output queue hence the current implementation conceptually works for address trees as is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed, thanks!
a3c5f20
to
61346cb
Compare
if self.verify_input_queue_batch_ready(&mut rpc).await { | ||
BatchReadyState::ReadyForNullify | ||
} else if self.verify_output_queue_batch_ready(&mut rpc).await { | ||
BatchReadyState::ReadyForAppend | ||
} else { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two thoughts:
- what about switching this checking
verify_output_queue_batch_ready
with priority since I expect more output state creation than input state creation? - There could be a case where the forester isn't fast enough and one queue is filled so fast that the forester neglects the other queue. Probably not the right time to focus on this right now but makes sense to keep this in mind.
No description provided.