[zk-token-proof] include VerifyBatchRangeProofU256 in the enable_zk_transfer_with_fee feature gate

[samkim-crypto]

Problem

The VerifyBatchRangeProofU256 instruction allows users to create a "batched" range proof on a sequence of commitments. The individual bit-lengths of the encoded values in these commitments must some up to 256.

Technically this allows a user to create a range proof of a single 256-bit committed value. This is theoretically fine, but since elliptic curve group is defined over a 256-bit prime number, it could lead to some unexpected consequences/security issues in the future. It would be good to restrict the individual bit-lengths in the batched range proof to be at most 128.

Summary of Changes

Since VerifyBatchRangeProofU256 is technically only required for transfer with fee, include the instruction as part of the transfer with fee feature gate.

Fixes #

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (d3690dd) 81.8% compared to head (0e4fd49) 81.8%.
Report is 37 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff            @@
##           master   #34747     +/-   ##
=========================================
- Coverage    81.8%    81.8%   -0.1%     
=========================================
  Files         824      824             
  Lines      222692   222694      +2     
=========================================
- Hits       182314   182264     -50     
- Misses      40378    40430     +52     

[joncinque]

Looks good to me! Does this need to get backported to 1.17?

[samkim-crypto]

Ah yes, it will need to be backported to 1.17. I'll add the tag.

[mergify]

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.