Dory: add layout enum + AddressMajor support #1197

quangvdao · 2026-01-08T13:31:38Z

Summary

This PR introduces an explicit Dory matrix layout selector and adds an AddressMajor layout implementation, while preserving existing CycleMajor behavior as the default.

Motivation

We need to support an alternate OneHot/Dory layout used by other implementations without silently changing existing proof behavior.

What’s included

DoryLayout enum (CycleMajor, AddressMajor) + global DoryGlobals::{get_layout,set_layout}.
Layout-aware OneHot polynomial operations used by Dory:
- row commitments (commit_rows)
- VMV / VMP (vector_matrix_product)
- evaluation path (evaluate)
Layout-aware dense path in RLCPolynomial for AddressMajor (CycleMajor preserved).
Tests:
- address/cycle ↔ index conversions
- global layout state
- dense polynomial commitment invariant across layouts
Up-to-date with a16z/jolt:main.

Layout definition

Let K = number of addresses, T = number of cycles.

CycleMajor (current default):
- linear index: idx = address * T + cycle
- coefficients are then placed into the Dory matrix in row-major order with row length = num_columns.
AddressMajor:
- linear index: idx = cycle * K + address
- coefficients are then placed into the Dory matrix in row-major order with row length = num_columns.

How to enable AddressMajor

Call before any Dory initialization / prover work:

use crate::poly::commitment::dory::{DoryGlobals, DoryLayout};

DoryGlobals::reset();
DoryGlobals::set_layout(DoryLayout::AddressMajor);
// then initialize contexts as usual

Testing

cargo test -p jolt-core --lib -- dory_layout --nocapture
cargo test -p jolt-core --lib -- zkvm::prover::tests::sha3_e2e_dory --exact --nocapture

Introduces DoryLayout enum for row-major and column-major coefficient mapping. Includes global state management and updated commitment logic. Co-authored-by: quang.dao <[email protected]>

Co-authored-by: quang.dao <[email protected]>

Update test parameters to match and add E2E tests for Dory layouts. Co-authored-by: quang.dao <[email protected]>

This commit introduces the AddressMajor layout for Dory, enabling more efficient polynomial commitments. It includes updates to OneHotPolynomial, RLCPolynomial, and DoryGlobals to handle the new layout. The verifier is also updated to initialize DoryGlobals with the new layout. Co-authored-by: quang.dao <[email protected]>

This commit completes the AddressMajor layout implementation by updating the core algorithms in OneHotPolynomial and RLCPolynomial: - Updated OneHotPolynomial::num_rows() to be layout-aware - Implemented commit_rows_address_major() with cycle-based row indexing - Implemented vector_matrix_product_address_major() for correct VMV - Updated RLCPolynomial to handle AddressMajor for dense polynomials - Added get_dimension() and get_cycles_per_row() helper methods - Fixed test num_vars consistency to avoid generator cache conflicts The two layouts differ in how coefficients are organized: - CycleMajor: index = address * T + cycle (groups by address) - AddressMajor: index = cycle * K + address (groups by cycle)

moodlezoup

in https://github.com/a16z/jolt/pull/996/files#diff-bcd74093e182e3cebb7ddcc4f3c4c251928a4c4a53615f8c42be8f815b7a22df, I had to make changes to the opening point passed to Dory in order to support address-major matrix layout. Why do we no longer need those changes?

moodlezoup · 2026-01-09T15:23:05Z

jolt-core/src/zkvm/verifier.rs

        // Parameters are computed from trace length as needed

+        // Initialize Dory globals for the verifier
+        // The verifier needs these to compute commitments during verification


this comment is a bit misleading

I don't think we need to do this anyways, so I'm deleting it.

moodlezoup · 2026-01-09T15:25:35Z

jolt-core/src/poly/commitment/dory/tests.rs

+    /// Test that dense polynomials produce the same commitment regardless of layout.
+    ///
+    /// The CycleMajor vs AddressMajor distinction only affects OneHot polynomials.
+    /// For dense polynomials, the matrix storage is always row-major.


I don't think this is true, I don't understand why this test is passing. Dense polynomials are treated as having K=1

moodlezoup · 2026-01-09T15:32:07Z

jolt-core/src/poly/commitment/dory/wrappers.rs

-                })
-                .collect(),
+            MultilinearPolynomial::LargeScalars(poly) => {
+                if address_major && poly.Z.len() == t {


I think the len == t checks throughout this file are unnecessary? All non-one-hot polynomials should be length T

moodlezoup · 2026-01-09T15:34:08Z

jolt-core/src/poly/commitment/dory/wrappers.rs

+    // AddressMajor embedding for cycle-only dense polynomials (len == T):
+    // use bases at stride K (col = cycle_offset * K) and chunk coefficients by cycles_per_row.
+    macro_rules! compute_dense_address_major_msm {
+        ($coeffs:expr, $msm_method:ident) => {{
+            let t = DoryGlobals::get_T();
+            if DoryGlobals::get_layout() == DoryLayout::AddressMajor && $coeffs.len() == t {


The comment and name for this macro seem to be inaccurate, as it handles the CycleMajor case in the else block. can we just fold this into the existing compute_msm! macro?

moodlezoup · 2026-01-09T15:46:50Z

jolt-core/src/poly/one_hot_polynomial.rs

+        // This batching helper was originally written for CycleMajor and is not currently
+        // performance-critical. For AddressMajor, fall back to per-polynomial commits to


we're not using this function anywhere anymore, we can just delete it

moodlezoup · 2026-01-09T16:00:18Z

jolt-core/src/poly/rlc_polynomial.rs

        result
    }
+
+    /// AddressMajor lazy VMV over lazy trace iterator (experimental, re-runs tracer).


given that we don't plan to use address-major on CPU (except for testing), I prefer to remove all the streaming-related codepaths. Wdyt?

cursoragent and others added 8 commits January 8, 2026 07:15

feat: Add Dory matrix layout support

773036f

Introduces DoryLayout enum for row-major and column-major coefficient mapping. Includes global state management and updated commitment logic. Co-authored-by: quang.dao <[email protected]>

Refactor Dory layout to support AddressMajor for OneHot polynomials

1a528f5

Co-authored-by: quang.dao <[email protected]>

feat: Add Dory layout tests and update parameters

b35b8af

Update test parameters to match and add E2E tests for Dory layouts. Co-authored-by: quang.dao <[email protected]>

Merge origin/main into cursor/dory-layout-investigation-and-enum-bde1

9a1f980

Fix build after merging main (DoryGlobals init + preprocessing API)

76fb1b8

Refactor Dory layout plumbing; fix AddressMajor dense + streaming VMV

6776274

quangvdao changed the title ~~Dory: add layout enum + AddressMajor support (GPU-compatible)~~ Dory: add layout enum + AddressMajor support Jan 8, 2026

fmt

fa48c7d

markosg04 self-requested a review January 8, 2026 16:55

moodlezoup reviewed Jan 9, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Dory: add layout enum + AddressMajor support #1197

Dory: add layout enum + AddressMajor support #1197

quangvdao commented Jan 8, 2026 •

edited

Loading

Uh oh!

moodlezoup left a comment

Uh oh!

moodlezoup Jan 9, 2026

Uh oh!

markosg04 Jan 9, 2026

Uh oh!

moodlezoup Jan 9, 2026

Uh oh!

moodlezoup Jan 9, 2026

Uh oh!

moodlezoup Jan 9, 2026

Uh oh!

moodlezoup Jan 9, 2026

Uh oh!

moodlezoup Jan 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

		// This batching helper was originally written for CycleMajor and is not currently
		// performance-critical. For AddressMajor, fall back to per-polynomial commits to

Dory: add layout enum + AddressMajor support #1197

Are you sure you want to change the base?

Dory: add layout enum + AddressMajor support #1197

Conversation

quangvdao commented Jan 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Motivation

What’s included

Layout definition

How to enable AddressMajor

Testing

Uh oh!

moodlezoup left a comment

Choose a reason for hiding this comment

Uh oh!

moodlezoup Jan 9, 2026

Choose a reason for hiding this comment

Uh oh!

markosg04 Jan 9, 2026

Choose a reason for hiding this comment

Uh oh!

moodlezoup Jan 9, 2026

Choose a reason for hiding this comment

Uh oh!

moodlezoup Jan 9, 2026

Choose a reason for hiding this comment

Uh oh!

moodlezoup Jan 9, 2026

Choose a reason for hiding this comment

Uh oh!

moodlezoup Jan 9, 2026

Choose a reason for hiding this comment

Uh oh!

moodlezoup Jan 9, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

quangvdao commented Jan 8, 2026 •

edited

Loading