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

pmonitor: create client activity monitor #4844

Merged
merged 32 commits into from
Oct 17, 2024
Merged

pmonitor: create client activity monitor #4844

merged 32 commits into from
Oct 17, 2024

Conversation

redshiftzero
Copy link
Member

@redshiftzero redshiftzero commented Aug 29, 2024

Describe your changes

This PR adds a tool pmonitor that will enable one to monitor the activity of a list of FullViewingKeys

Plan:

  • Make a new tool pmonitor (because we need to use pclientd or pcli which assumes a single view key)
  • Load a JSON file containing a array of FullViewingKeys
  • Build a directory tree that has pcli/pclientd home directories that have view databases and have the current state
  • One off scanning of the compact block with each FVK to determine the genesis allocation for that FVK
  • For each FVK, check the current UM-equivalent balance for the balance is greater than or equal to the genesis balance
  • Print each FVKs, their genesis balance, and their current UM-equivalent balance
  • Handle migrated accounts

Issue ticket number and link

Will close #4832

Test

  1. Point to the desired RPC and provide a JSON array of FVKs: cargo run --bin pmonitor init --fvks test.json --grpc-url https://yourtestnetrpchere.example.com

Expected state: you should have in your zone.penumbra.pmonitor home directory (stored next to wherever your pcli default homedir is, so on my Macbook it's "/Users/redshiftzero/Library/Application Support/zone.penumbra.pmonitor") a:

  • config file
  • for each FVK, a wallet_{uuid} directory
  1. Run cargo run --bin pmonitor audit:
Syncing wallet: /Users/redshiftzero/Library/Application Support/zone.penumbra.pmonitor/wallet_3
Scanning blocks from last sync height 286483 to latest height 286483
[0s] ██████████████████████████████████████████████████       0/0       0/s ETA: 0s
Wallet synced successfully
FVK: penumbrafullviewingkey1[...snip...]
Genesis UM-equivalent balance: 0
Current UM-equivalent balance: 2999999066
✅ Expected balance! Balance is greater than or equal to the genesis balance
...

This will first sync all the wallets, then check the balances. Subsequent executions of the audit command will start with the state from the previous run.

Note: To reset after testing:
cargo run --bin pmonitor reset

Checklist before requesting a review

  • If this code contains consensus-breaking changes, I have added the "consensus-breaking" label. Otherwise, I declare my belief that there are not consensus-breaking changes, for the following reason:

    This is a client-side tool only

@conorsch
Copy link
Contributor

We just shipped the pcli-migrate-balance functionality (#4831), which enables full-wallet transfers, based on FVK. The pmonitor tool should recognize a migrated balance, which can be identified by a hardcoded memo: https://github.com/penumbra-zone/penumbra/blob/v0.80.4/crates/bin/pcli/src/command/migrate.rs#L105

@aubrika
Copy link
Contributor

aubrika commented Sep 17, 2024

Sounds like this will be wrapped up or close this week, and since this is a read-only op, whoever reviews this should be sure to test against both testnet and mainnet. I can help generate a list of FVKs and checking the implementation should be straightforward from there.

@redshiftzero
Copy link
Member Author

status: this now has support for migrated accounts, but needs testing before marking ready for review

@conorsch conorsch self-requested a review September 23, 2024 20:11
@conorsch
Copy link
Contributor

I'll take a first pass at review here, confirming that the tool 1) correctly identifies when accounts have been spent out of; and 2) supports the pcli-migrate-balance flow.

@conorsch conorsch changed the title wip: add client activity monitor pmonitor: add client activity monitor Sep 23, 2024
@conorsch conorsch changed the title pmonitor: add client activity monitor pmonitor: create client activity monitor Sep 23, 2024
@conorsch conorsch marked this pull request as ready for review September 26, 2024 22:46
Copy link
Contributor

@conorsch conorsch left a comment

Choose a reason for hiding this comment

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

In terms of functionality, the tool appears to work well: in all the testing I've done, it correctly notates when balance is absent. Still more interactive testing to perform, but the implementation seems sound!

UX-wise, however, the tool obscures detection of misbehavior: any indication of a misbehavior is likely lost to scrollback in the default stdout, where there are more than, say, 5 FVKs to scan. Worse, the tool exits 0 regardless of whether misbehavior was detected. Suggestions to resolve:

  1. emit a "summary" message at the end of the audit run, notating explicitly if any accounts were found to have funds missing;
  2. designate a specific exit code, e.g. 10, for signaling that misbehavior was detected; that will allow the tool to be run in headless environments on a schedule, without resorting to string parsing;
  3. (optional) convert the per-account messaging to tracing-subscriber statements, subject to RUST_LOG tweaking, to enable focusing on the summary message.

I left some in-line comments throughout, and also pushed up a script I've been using locally to test on a devnet. The biggest complaint I have about the technical bits are that the tool assumes it can cargo run --bin pcli, which I'd prefer to address before merge.

}

// Invoke pcli to initialize the wallet (hacky)
let output = ProcessCommand::new("cargo")
Copy link
Contributor

Choose a reason for hiding this comment

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

Let's not assume that we have a full rust env and the git repo relative to the cwd for the command. Once the pmonitor binary is built, it should have everything it needs to interact with external services and perform the check, regardless of where it's executed.

Looks like not everything we need is already pub in pcli, but could be. Also willing to default to calling pcli directly, rather than cargo run --bin pcli, because then we can at least error out if not found and provide a helpful error msg.

height_created = excluded.height_created,
address_index = excluded.address_index,
source = excluded.source,
height_spent = excluded.height_spent,
Copy link
Contributor

Choose a reason for hiding this comment

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

Note to self: there's whitespace trimming in these SQL statements, but also a substantive schema change below.

@@ -54,7 +54,8 @@ CREATE TABLE tx (
tx_hash BLOB PRIMARY KEY NOT NULL,
tx_bytes BLOB NOT NULL,
block_height BIGINT NOT NULL,
return_address BLOB
return_address BLOB,
memo_text TEXT
Copy link
Contributor

Choose a reason for hiding this comment

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

Schema change! This breaks existing clients. Testing locally against testnet, I do indeed see the error message:

Error: can't load view database created by client version 0.80.5 using client version 0.80.5: they have different schemata, so you need to reset your view database and resynchronize by running pcli view reset

That's probably tolerable for a point-release, but we should be careful about downstream consequences. I'm thinking in particular of relayers like hermes, which will likely fail when their deps are upgraded to a more recent view crate. I see we already merged a schema change in #4801 so we'll need to accommodate for the change already anyway. Relevant for rebasing the hermes fork, cc @zbuc.

if total_um_equivalent_amount < genesis_um_equivalent_amount {
println!("✘ Unexpected balance! Balance is less than the genesis balance");
} else {
println!("✅ Expected balance! Balance is greater than or equal to the genesis balance");
Copy link
Contributor

Choose a reason for hiding this comment

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

Love the emojis, makes the wall of text a bit easier to scan visually. I only tested with 10 FVKs, though, and most of the relevant content was off the screen. Maybe tracing statements would be more appropriate here.

@conorsch
Copy link
Contributor

conorsch commented Oct 7, 2024

Rebased on latest main, and added a handful of commits. Logging is now more verbose, but still TK are summary message and custom exit codes. During testing, I noticed that the tool will report an error if an account was migrated: we should refactor the audit logic to continue searching the migrated account, without reporting an error, or else explicitly state that a new migration was detected and therefore the tool should be rerun.

@conorsch conorsch added the pr-needs-testing Before being mergeable, this PR should add tests to the code, or have a human perform tests label Oct 7, 2024
redshiftzero and others added 18 commits October 11, 2024 14:38
Previously if an FVK was in the monitoring list that did not have
a genesis allocation, we'd bail out. Instead, let's just note that
its genesis balance is 0, and continue on.
Prefers `tracing_subscriber` logging over standard `println` messages,
so that verbosity of output is customizable.

Sorts the deps in pmonitor manifest.

refactor: remove unwraps
Pretty sure this is strictly necessary: in order to detect the substring
message in a memo text, we must perform the sql query via `sqlx` by
providing wildcard characters like `%`. Updated query calls and
associated docstrings.
The mismatch between view db filenames was causing some confusing
behavior. Updated for consistency between both pcli and the pmonitor
view service.
Uses `colorize` dep for pretty-printing human-readable message.
Adds automated testing of common use cases for the `pmonitor` FVK
audit tool. The cargo tests are adapted from a one-off bash script
written to aid in review of the original pmonitor PR.

ci: add pmonitor integration workflow

ci: adjust smoke concurrency

ci: load rust cache
@conorsch
Copy link
Contributor

Looking great. I added some tests, and made some changes to implement the requested features, namely 1) summary message at end of run, and 2) exiting non-zero on failure.

Example output from passing audit

pmonitor-pass

Example output from failing audit

pmonitor-fail

Also tacked on some module docs to explain how it's intended to be used. Haven't added any content to the guide, but we can do that in a follow up if it's useful.

@conorsch conorsch self-requested a review October 11, 2024 21:48
@conorsch conorsch removed the pr-needs-testing Before being mergeable, this PR should add tests to the code, or have a human perform tests label Oct 11, 2024
@redshiftzero
Copy link
Member Author

thank you for adding these changes @conorsch, I've reviewed them (as of eec9d25) and they LGTM

@conorsch conorsch merged commit 954e777 into main Oct 17, 2024
14 checks passed
@conorsch conorsch deleted the client-activity branch October 17, 2024 22:52
@conorsch conorsch mentioned this pull request Oct 22, 2024
3 tasks
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.

client: account activity monitor
3 participants