AVM: Reassess ECDSA opcode cost with secp256r1 curve

[michaeldiamant]

Problem

#3495 adds an ECDSA curve (secp256r1) that leaves related opcode costs unchanged although there's a performance overhead. Since the opcode costs underprice the runtime cost, there's AVM execution may not match advertised throughput levels.

Context:

• [WIP] Secp256r1 support for ECDSA verify and decompress opcodes #3495 is merged into AVM: FIDO2 OpCodes #3514.
• AVM: FIDO2 OpCodes #3514 deliberately gates secp256r1 behind a future version. So, the curve is not available for general consumption.

Solution

Unclear how best to proceed. Here's the loosely discussed ideas:

• Since the opcode cost is not specific to each curve, a conservative option is to make opcode costs reflect the most costly curve. Obviously, the solution penalizes less costly curves.
• Provide static opcode costs varied by immediate arguments (like different curves). The proposal offers a general-purpose way to customize opcost costs.
  • Tangentially related: Provide dynamic opcode costs. For example, vary opcode cost by input size. The change may not be needed solve the ticketed concern. Though it may be prudent to consider implications while making changes here.

Dependencies

N/A

Urgency

TBD