Addresses the following review comments:
- "I'd rename all mask_3 references in test names and variables to a
private pda wording. If in the future we change the mask number for
the private pda, this naming will silently get outdated."
I renamed all tests and the local variable mask3_account to
private_pda_account.
- "Let's use more descriptive names. `mask3` is not very meaningful."
I renamed all `mask3` into `private_pda`. Panic messages and .expect
strings updated to match. Doc comments that factually describe the
encoding (e.g. "mask-3 account" meaning "an account whose visibility
mask is 3") are left as-is since they are accurate and remain stable
until the mask value itself changes.
- "..._panics" to "..._fails"
Covered above. The tests assert Err(CircuitProvingError), so
execute_and_prove returns an Err, the test process itself never
panics.
- "we can return `Some((*seed, true, caller))` to avoid having to unwrap
the `caller_program_id` again in line 290"
I changed matched_caller_seed from Option<(PdaSeed, bool)> to
Option<(PdaSeed, bool, ProgramId)>, return the `caller` captured by
the enclosing and_then from each match arm, and dropped the .expect
at the consumer site. Bundled with the rename since both touch the
same branch and a single guest ELF rebuild covers them.
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).
