Addresses the following review comments:
- "I'd keep this crate independent of wallet references"
I replaced all with "supplied npk".
- Rename request on locals attested_keys/wallet_keys
In mask_3_wallet_npk_mismatch_panics the two key sets play distinct
roles, one produces the pre_state's account_id (the registered pair)
and the other is supplied in private_account_keys as the mismatched
npk. Collapsing both to `keys` would be misleading. I renamed to
keys_a and keys_b with an inline comment noting which one is the
registered one and which one is mismatched.
Addresses the following review comments:
- "Isn't two_mask_3_claims_under_same_seed_are_rejected already checking
that there's a mechanism protecting against this exploit scenario?"
The doc block at nssa/src/state.rs:2488-2504 mixes three paragraphs,
one about reuse, one TODO about wallet side input, one exploit pin,
all attached to two_mask_3_claims_under_same_seed_are_rejected. The
reuse test below it had no doc at all. I split as follows: the
exploit-pin paragraph stays on two_mask_3_claims_..., the reuse
paragraph moves to a fresh docstring on
mask_3_reuse_across_txs_currently_unsupported.
- "I don't understand this. I think this should fail because ... the
input pre_state which is marked with is_authorized=true will make
things fail."
The reuse test's new docstring cites the actual reject site, the
post-loop private_pda_bound_positions assertion in
privacy_preserving_circuit.rs:185-192. At top level the Entry::Vacant
arm accepts is_authorized=true unconditionally, the rejection comes
from the bound-positions check firing because noop emits no Claim::Pda
and there is no caller ChainedCall.pda_seeds.
- "let's dont have this TODO as part of the doc"
The block is moved out into regular // comments immediately above
mask_3_reuse_across_txs_currently_unsupported.
- "let's not add implementation details to docs"
In caller_pda_seeds_authorize_mask_3_private_pda_for_callee's
docstring, I dropped the parenthetical "(Occupied branch)" and the
trailing sentence about which validate_and_sync_states code path gets
exercised.
- "what does \`Claim::Pda(seed)\` / \`pda_seeds\` mean?"
I rewrote the pda_family_binding docstring at
privacy_preserving_circuit.rs:33-39: replaced the ambiguous
"Claim::PrivatePda and ChainedCall's private seeds into plain
Claim::Pda(seed) / pda_seeds" phrase with "a Claim::Pda(seed) in a
program's post_state or a caller's ChainedCall.pda_seeds entry".
- Suggestion on nssa/src/validated_state_diff.rs:226 rewriting
"The public-execution path only sees mask-0 accounts" to
"The public-execution path only sees public accounts".
Applied: "The public-execution path only sees public accounts".
- Clarification requested on the private_pda_bound_positions field:
I expanded the docstring at privacy_preserving_circuit.rs:26-31 to
state that binding is an idempotent property, not an event, and to
enumerate the two proof paths that populate it (a Claim::Pda on a
mask-3 pre_state, or a caller's pda_seeds matching under the private
derivation).
The pda_mechanism_with_pinata_token_program test was broken after
PR #414 introduced Claim::Authorized for token account claiming.
Set up token accounts directly to focus the test on the PDA mechanism
in the pinata program's chained call.
