Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

compute quotient codewords more efficiently #114

Closed
jan-ferdinand opened this issue Nov 10, 2022 · 0 comments · Fixed by #124
Closed

compute quotient codewords more efficiently #114

jan-ferdinand opened this issue Nov 10, 2022 · 0 comments · Fixed by #124
Labels
🤖 code Changes the implementation ✨ enhancement Improvement or new feature 🟡 prio: medium Not super urgent ⏩ speedup Makes stuff go faster.

Comments

@jan-ferdinand
Copy link
Member

Proving correct execution of Triton VM involves computing quotient codewords, whose low-degreeness is then proved using FRI. In order to compute the quotient codewords, we first need the so-called FRI codewords. There are several ways to compute them, all of which are equivalent conceptually, but not computationally. For example, following the red path in the picture below, the AIR constraints can be evaluated on the (symbolic) trace polynomials, resulting in {initial, consistency, transition, terminal} polynomials, which can then be low-degree extended. This is generally very slow.

In Triton VM, we currently follow the gray-into-orange path, i.e., we perform low-degree extension first, and then evaluate the AIR constraints on the FRI trace codewords1.

The fastest way is indicated by the green path. Here, we introduce a new domain, the arithmetic domain, which is smaller than the FRI domain by a factor of expansion_factor, i.e., 4. After having evaluated the AIR constraints on the trace codewords (over the arithmetic domain), low-degree extension is performed on the {initial, consistency, transition, terminal} codewords, resulting in the sought-after FRI codewords. Following the green path instead of the orange path is (projected to be) a speedup with factor 4.

As far as I know, all credit for the idea goes to @aszepieniec.

Footnotes

  1. This name is not used anywhere yet – up until now, we did not need to distinguish between trace codewords over the arithmetic domain and over the FRI domain.

@jan-ferdinand jan-ferdinand added ✨ enhancement Improvement or new feature 🟡 prio: medium Not super urgent 🤖 code Changes the implementation ⏩ speedup Makes stuff go faster. labels Nov 10, 2022
sshine added a commit that referenced this issue Nov 22, 2022
The main advancement of this release is the use of performance-optimized
arithmetic circuits instead of multivariate polynomials for expressing
constraints. (cd62c59)

- Depend on twenty-first-0.7.0
- Don't multiply randomizer codeword by random weight (#139)
- Replace `Replace `Result<T, Box<dyn Error>>` with `anyhow::Result<T>`) (#134)
- Use quotient domain instead of FRI domain wherever applicable (#114)
- Fix bug in the decoding procedure for `Vec<PartialAuthenticationPath>` (e7fd6cc)
- Run 'cargo fmt' after constraint-evaluation-generator (2d183e4)
- Add prove_fib_100 benchmark for STARK proving (1326b12)
- Replace TimingReporter with TritonProfiler (c40c1bc)
- Add "TIP 0004: Drop U32 Table"
- Drop `VecStream` in favor of `Vec<BFieldElement>`

PR #125:
- Generate all constraints as circuits
- Remove memoization of AIR constraints
- Bypass MPolynomial Representation of AIR Constraints
- Create Makefile, use Makefile in CI
- Auto-generate Quotientable trait instances
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🤖 code Changes the implementation ✨ enhancement Improvement or new feature 🟡 prio: medium Not super urgent ⏩ speedup Makes stuff go faster.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant