Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
A Master Table is, in some sense, a top-level table of Triton VM. It
contains all the data but little logic beyond bookkeeping and presenting
the data in a useful way. Conversely, the individual tables contain no
data but all of the respective logic. Master Tables are responsible for
managing the individual tables and for presenting the right data to the
right tables, serving as a clean interface between the VM and the
individual tables.
As a mental model, it is perfectly fine to think of the data for the
individual tables as completely separate from each other. Only the
cross-table argument links all tables together.
Conceptually, there are three Master Tables: the Master Base Table, the
Master Extension Table, and the Master Quotient Table. The lifecycle of
the Master Tables is as follows:
1. The Master Base Table is instantiated and filled using the Algebraic
Execution Trace. This is the first time a Master Base Table is
instantiated. It is in column-major form.
2. The Master Base Table is padded using logic from the individual
tables.
3. The still-empty entries in the Master Base Table are filled with
random elements. This step is also known as “trace randomization.”
4. Each column of the Master Base Table is low-degree extended. The
result is the Master Base Table over the FRI domain. This is the
second and last time a Master Base Table is instantiated. It is in
row-major form.
5. The Master Base Table and the Master Base Table over the FRI domain
are used to derive the Master Extension Table using logic from the
individual tables. This is the first time a Master Extension Table
is instantiated. It is in column-major form.
6. The Master Extension Table is trace-randomized.
7. Each column of the Master Extension Table is low-degree extended.
The result is the Master Extension Table over the FRI domain. This
is the second and last time a Master Extension Table is
instantiated. It is in row-major form.
8. Using the Master Base Table over the FRI domain and the Master
Extension Table over the FRI domain, the Quotient Master Table is
derived using the AIR. Each individual table defines that part of
the AIR that is relevant to it.
The following points are of note:
- The Master Extension Table's rightmost columns are the randomizer
codewords. These are necessary for zero-knowledge.
- The terminal quotient of the cross-table argument, which links the
individual tables together, is also stored in the Master Quotient
Table. Even though the cross-table argument is not a table, it does
define part of the AIR. Hence, the cross-table argument does not
contribute to padding or extending the Master Tables, but is
incorporated when deriving the Master Qoutient Table.
- For better performance, it is possible to derive the Master Quotient
Table (step 8) from the Master Base Table and Master Extension Table
over a smaller domain than the FRI domain – the “quotient domain.”
The quotient domain is a subset of the FRI domain. This performance
improvement changes nothing conceptually.
- global indexing into master tables
- fill in trace for individual tables
- pad individual tables
- extend individual tables
- remove old logic for trace filling, padding, and extending
- add randomizer polynomials to master extension table
- trace-randomize master tables
- perform low-degree extension in parallel
- build Merkle trees from master tables
- get quotient degree bounds of individual tables
- compute quotient codewords using master tables
- avoid recomputing zerofiers by building quotients by type, not table
- one place to store all quotients – “master quotient table”
- including `GrandCrossTableArg` as a first-class citizen
- adapt multicircuits to use master tables
- adapt code generator correspondingly
- remove multivariate polynomials from multicircuits
- use type layout `#[repr(usize)]` for `*Table*Column` to safely allow
indexing with compile-time known indices
- update specification:
- remove unenforceable Ram Table constraints
- add new column “previous instruction”
- with the necessary constraints
- don't require the Ram Table to be sorted by `ramp`
- documentation, tests, cheatsheet, …
Fix #11, fix #119, fix #120, fix #139, fix #148, fix #155.- Loading branch information
