Master Tables

[jan-ferdinand]

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.

---

• one place to store data for all tables – “master base table”
• one place to store all extension columns, which link individual tables – “master extension table”
• 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, where they can live in their native field
• trace-randomize master tables
• perform low-degree extension in parallel and as in-place as currently possible
• 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 with respect to
  • remove unenforceable Ram Table constraints (enforce RAM initializating to all zero #155)
  • add new column “previous instruction” and the necessary constraints surrounding it
  • don't require the Ram Table to be sorted by ramp, which is unenforceable anyway
• documentation, tests, cleanup, et cetera

---

Fix #11, fix #119, fix #120, fix #139, fix #148, fix #155.

[jan-ferdinand]