chore(tests): add modexp length mismatch functionality

[spencer-tb]

🗒️ Description

Aims to update the modexp helpers to allow for length mismatch tests.

Length mismatch tests can be added with the following, copied over and refactored from #2044.

pytest.param(
    ModExpInput(
        base=b"",
        exponent=Bytes("80"),
        modulus=b"",
        declared_exponent_length=2**64,
    ),
    id="exp_2_pow_64_base_0_mod_0",
),

🔗 Related Issues or PRs

Fixes #2043 (attemps to).

✅ Checklist

• All: Ran fast tox checks to avoid unnecessary CI fails, see also Code Standards and Enabling Pre-commit Checks:

  uvx --with=tox-uv tox -e lint,typecheck,spellcheck,markdownlint

• All: PR title adheres to the repo standard - it will be used as the squash commit message and should start type(scope):.
• All: Considered adding an entry to CHANGELOG.md.
• All: Considered updating the online docs in the ./docs/ directory.
• All: Set appropriate labels for the changes (only maintainers can apply labels).

[chfast]

This is still not fully consistent and I don't think you can reliably compute gas using this higher level structure. One reason is pointed out in the inline comment. Another reason is you can use raw_input= (and there are good reasons to do so) and then all the additional properties (e.g. length_base) are garbage. Same as the computed gas.

This precompile has ultimately complex input structure. If you want something reliable consider this: you can have reach set of constructors and/or constructor arguments for readability. But you should immediately build input bytes out of them. And the gas cost must be computed from bytes. EELS has it already so you can copy the code for start.

[chfast]

This doesn't fully solve the problem because you pass exponent which may mean this is only the part of the exponent but the function will treat it as full. So this computation may give incorrect results.

[LouisTsai-Csie]

We can take inspiration from the EELS implementation, which resolve this problem in an elegant way.

According to eip-7883, the iteration count is derived from the exponent. However, in practice we only need at most 32 bytes of the exponent.

def calculate_iteration_count(exponent_length, exponent):
    iteration_count = 0
    if exponent_length <= 32 and exponent == 0:
        iteration_count = 0
    elif exponent_length <= 32:
        iteration_count = exponent.bit_length() - 1
    elif exponent_length > 32:
        iteration_count = (16 * (exponent_length - 32)) + ((exponent & (2**256 - 1)).bit_length() - 1)
    return max(iteration_count, 1)

• When exponent_length <= 32, we can compute the bit length of the full exponent directly.
• When exponent_length > 32, we mask the exponent to its 32 bytes and calculate the bit length of that portion: (exponent & (2**256 - 1)).bit_length() - 1

As a result, we only need to fetch the first 32-byte word of the exponent input (exponent_head) to perform this calculation, instead of processing the entire exponent.

[chfast]

This feels a bit too much for me. I generally struggle with some data types in EEST which have a lot of interconnected options and flags.

This could be a normal constructor. And you can fix the properties directly in the constructor like:

length_base = declared_base_length if  declared_base_length not None else len(base)

[spencer-tb]

Updated regarding the comments using the EELS like approach..