refactor: remove 8 bit portion of the range checker

[tohrnii]

Describe your changes

Addressing #395. Simplifies the range checker design by removing the 8-bit segment of the range checker table. This however increases the minimum length of the trace since we can no longer use the 8-bit table after this change to allow jumps of $2^8$ and instead can only allow jumps of 8 because that requires a constraint of degree 9. The following constraint ensures consistency of the range checker table.

$$ \prod_{i=0}^8 (\Delta v - i) = 0 $$

• Modify the shape of the trace and trace generation
• Update AIR constraints
• Update tests
• Update docs
• Modify testing methodology to reduce test run-times.

Checklist before requesting a review

• Repo forked and branch created from next according to naming convention.
• Commit messages and codestyle follow conventions.
• Relevant issues are linked in the PR description.
• Tests added for new functionality.
• Documentation/comments updated according to changes.

[bobbinth]

If I'm reading test runtimes correctly, it seems that they increased by 30% - 40% - is this right? If so, maybe it's not too bad. If there are some simple ways to reduce them, we can do that now - but if not, we can leave that for future PRs.

[tohrnii]

If I'm reading test runtimes correctly, it seems that they increased by 30% - 40% - is this right?

On M1 with 8 cores, it goes from ~47 seconds to ~500 seconds for integration tests.

[bobbinth]

On M1 with 8 cores, it goes from ~47 seconds to ~500 seconds for integration tests.

Is this via make test command?

[tohrnii]

Is this via make test command?

Ah, that was using cargo test without any flags. Using make test you're right it's around 30% increase.

[bobbinth]

Ah, that was using cargo test without any flags. Using make test you're right it's around 30% increase.

make test is what we use to run tests in CI (and also locally) - so, I'd base analysis on these numbers. What do absolute numbers look like, btw?

[tohrnii]

4.04s -> 5.31s

[tohrnii]

@bobbinth Sorry, I ran it on the wrong branch earlier. It actually goes from ~4 to ~60 seconds.

[bobbinth]

It actually goes from ~4 to ~60 seconds.

Hmmm - could you double-check? A 15x increase seems rather high - I would have expected an 8x increase in the worst possible case.

[tohrnii]

Hmmm - could you double-check? A 15x increase seems rather high - I would have expected an 8x increase in the worst possible case.

Yeah, makes sense. The runtime number seems correct (checked 5 times). Let me look into it and get back.

[tohrnii]

Closing this PR since this design increases the minimum trace length to $2^{14}$ which is probably fine for the rollup but more than what we want for the VM.