[zk-token-sdk] Restrict Edwards and Ristretto multiscalar multiplication vector length to at most 512

[samkim-crypto]

Problem

The curve25519 syscalls have an operation called the multiscalar multiplication (MSM), which computes the inner product of a vector scalar and curve points. The larger the vectors are, the more expensive the MSM operation becomes. The assigned compute units for MSM's do take this growing cost into account, but there is no concrete bound on the size of the vectors.

Theoretically, an attacker could craft a number of txs with very large MSM inputs, which could lead to either:

• all validators spending more than 400ms to compute all the MSMs
• or some validators take more than 400ms and others less

It would be good to define the max size of the vectors for MSM for safety. For most practical applications, MSM of vector length 512 should be sufficient.

Summary of Changes

• Add a max cap of 512 vector length for the multiscalar multiplication syscall.
• The curve25519 syscalls are already activated on testnet and devnet, but not yet on MB. I created a new feature id and replaced the old feature id.

Fixes #

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (9468996) 81.7% compared to head (694c344) 81.8%. Report is 10 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master   #34763   +/-   ##
=======================================
  Coverage    81.7%    81.8%           
=======================================
  Files         825      825           
  Lines      223126   223164   +38     
=======================================
+ Hits       182507   182585   +78     
+ Misses      40619    40579   -40     

[mergify[bot]]

Backports to the beta branch are to be avoided unless absolutely necessary for fixing bugs, security issues, and perf regressions. Changes intended for backport should be structured such that a minimum effective diff can be committed separately from any refactoring, plumbing, cleanup, etc that are not strictly necessary to achieve the goal. Any of the latter should go only into master and ride the normal stabilization schedule. Exceptions include CI/metrics changes, CLI improvements and documentation updates on a case by case basis.