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

Improve speculative shielded ctx #4019

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

grarco
Copy link
Contributor

@grarco grarco commented Nov 13, 2024

Describe your changes

Closes #3457.
Closes #2593.

Moved the transition to the SpeculativeContext from the SDK to the client to have access to the (possible) tx result. The transition is now performed when:

  • the submitted transaction is successfully applied
  • the transaction is broadcasted
  • the transaction is dumped to storage

The transition is not performed when:

  • the transaction gets dry-run
  • the transaction is loaded from storage

Added an integration test to verify the behavior of the client when in a speculative context.

Checklist before merging

  • If this PR has some consensus breaking changes, I added the corresponding breaking:: labels
    • This will require 2 reviewers to approve the changes
  • If this PR requires changes to the docs or specs, a corresponding PR is opened in the namada-docs repo
    • Relevant PR if applies:
  • If this PR affects services such as namada-indexer or namada-masp-indexer, a corresponding PR is opened in that repo
    • Relevant PR if applies:

@grarco grarco marked this pull request as ready for review November 13, 2024 13:17
Comment on lines +943 to +956
match namada.submit(tx, &args.tx).await? {
ProcessTxResponse::Applied(resp) => {
if let Some(InnerTxResult::Success(_)) =
resp.batch_result().first().map(|(_, res)| res)
{
pre_cache_masp_data(namada, &masp_section).await;
}
}
ProcessTxResponse::Broadcast(_) => {
pre_cache_masp_data(namada, &masp_section).await;
}
// Do not pre-cache when dry-running
ProcessTxResponse::DryRun(_) => {}
}
Copy link
Contributor

Choose a reason for hiding this comment

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

this pattern is repeated a couple of times. could be abstracted into a method

Comment on lines +6162 to +6164
// The speculative context invalidates the entire note spent so we expect to
// see the balance coming only from the second unspent note
assert!(captured.contains("nam: 100"));
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we should emit a warning in this case, or prefix the token alias (ex: speculative {token}: {amount}). another reason to emit a warning is that by using an older anchor, as @batconjurer pointed out, we could be revealing when a note was first created. in an ideal scenario the user will always call shielded-sync, or we call it automatically again. IMO the only blocker for the latter would be improving the UX of canceling the shielded sync process, which takes a while to return control to the shell after hitting Ctrl+C.

Copy link
Member

@batconjurer batconjurer left a comment

Choose a reason for hiding this comment

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

Apart from sug0's requested changes, this looks fine

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Wrong shielded balance in query Improve Speculative ShieldedContext
3 participants