Add WebAuthn (secp256r1/P-256) signature verification for passkey support

[tac0turtle]

Summary

Add support for secp256r1 (P-256/prime256v1) signature verification to enable WebAuthn/passkey-based authentication alongside the existing secp256k1 ECDSA scheme.

Passkeys eliminate seed phrases and leverage device-native authentication (biometrics, PIN), significantly improving UX for end users.

Motivation

• UX: Passkeys are the industry direction for wallet auth — no seed phrases, no browser extensions, built into every modern OS and device.
• Adoption: WebAuthn is supported by all major browsers and platforms (Apple, Google, Microsoft). Billions of devices already have P-256 hardware support.
• Account Abstraction alignment: Supporting multiple signature schemes is a natural fit for account-driven architectures.

Scope

1. P-256 signature verification — Add ecrecover equivalent for secp256r1 in the STF.
2. WebAuthn payload parsing — Decode authenticator data + client data JSON per the WebAuthn spec.
3. Gas/fee metering — Price r1 verification appropriately (see tradeoffs).
4. Authentication module — Extend or create an auth account that supports both k1 and r1 signers.

Performance Tradeoffs

secp256r1 is slower than secp256k1 in pure software

On-chain verification is pure software (deterministic STF), so hardware acceleration is not available. Expected overhead:

Aspect	secp256k1	secp256r1
Point doubling	Faster (a=0 in y²=x³+7)	Slower (a=-3 in y²=x³-3x+b)
Scalar multiplication	GLV endomorphism (~30% speedup)	No equivalent optimization
Software verification	Baseline	~20-40% slower
Library maturity	libsecp256k1 (extremely optimized)	Good (p256, RustCrypto) but less specialized

Implications

• Gas pricing: r1 ecrecover must be priced higher than k1 to reflect actual compute cost. Underpricing creates a DoS vector.
• Throughput: At sub-millisecond per verification, the per-tx overhead is small. Becomes relevant only at very high TPS where signature verification dominates block processing time.
• Block gas limits: If r1 txs consume more gas per signature, fewer r1-signed txs fit per block compared to k1.

Where r1 wins (client side, not on-chain)

• Signing happens in secure enclave/TPM with hardware P-256 — effectively instant from user perspective.
• No private key management burden on the user.

Implementation Considerations

• Use p256 crate (RustCrypto) for verification — pure Rust, no C dependencies, audited.
• WebAuthn payloads include additional fields (challenge, origin, authenticator data) that must be parsed and validated deterministically.
• Consider whether to support both raw P-256 ECDSA and full WebAuthn envelope, or only WebAuthn.
• Signature malleability: enforce low-S normalization same as k1.

References

• WebAuthn spec (W3C)
• EIP-7212: Precompile for secp256r1
• RustCrypto p256 crate