Batching/commit by omibo · Pull Request #45 · LayerZero-Labs/hachi

omibo · 2026-04-07T21:14:18Z

WIP

Replace the `hachi_root_commitment_layout` fallback in the default `commitment_layout` impl with a direct call to the new `planner::compute_root_layout_dimensions`, which derives the root layout from SIS security tables and digit math. Also compute the commit layout directly via `hachi_batched_root_layout` instead of extracting it from `HachiRootRuntimePlan`. Made-with: Cursor

Extend `commitment_layout` to accept `num_claims` so the planner can optimize the (m_vars, r_vars) split for batched openings using a witness-size cost model with batched fold digits. Simplify `hachi_batched_root_layout` and `root_batched_layout` to delegate layout computation through `commitment_layout`. - Add `compute_num_digits_fold_batched` to planner digit math - Add batched m/r split optimization to planner layout module - Update all callers to pass num_claims (1 for single-poly) - Gate old `optimal_root_batch_split` behind #[cfg(test)] - Ignore 4 blessed schedule tests pending table regeneration Made-with: Cursor

cursor · 2026-04-07T21:14:24Z

PR Summary

Medium Risk
Changes how root commitment layouts are derived (including SIS-rank convergence and batched split optimization), which can affect proof sizes, setup parameter envelopes, and security assumptions if miscomputed. Some schedule-table exactness tests are now ignored pending regeneration, increasing regression risk around planned-vs-runtime consistency.

Overview
Root commitment layout selection is refactored to be planner-driven and batch-aware. CommitmentConfig::commitment_layout now takes (max_num_vars, num_claims) and, when no schedule plan is available, derives the root layout via a new planner routine (compute_root_layout_dimensions) that combines digit math with SIS security table constraints and converges n_a against the final inner width.

Batched root layout optimization is simplified and centralized. The previous bespoke batched root split search in commit.rs is removed; batched layouts now flow through Cfg::commitment_layout(..., num_claims), with root_batched_layout only switching to the planned/planner batched layout when the provided root layout matches the singleton planned root. A shared compute_num_digits_fold_batched is moved into planner::digit_math.

API plumbing updates across benches/tests and runtime. All call sites are updated to pass num_claims (typically 1), and commitment/verification paths use hachi_batched_root_layout/commitment_layout(..., 1) consistently; a few “exact schedule” tests are marked #[ignore] until schedule tables are regenerated.

^{Reviewed by Cursor Bugbot for commit 30bf4fc. Bugbot is set up for automated code reviews on this repo. Configure here.}

github-actions · 2026-04-07T21:16:30Z

Benchmark Report

Latest run: 37c7bec
Message: Merge 30bf4fc into 9c8bbaf
Ref: batching/commit
Main baseline: 9c8bbaf from merge-base on main.
Previous run: acc2e16 from the previous successful PR update.
Binary: target/release/examples/profile.
Memory: maximum resident set size from /usr/bin/time on the benchmark process.

Single Polynomial x 32 Variables

Benchmark: 1-of-256 one-hot with 32 variables
Sparsity: each polynomial is 1-of-256 one-hot (equivalently, 1-sparse over 256 slots, density 0.39%).
Command: target/release/examples/profile with HACHI_MODE=onehot HACHI_NUM_VARS=32 HACHI_NUM_POLYS=1 HACHI_PROFILE_TRACE=0 HACHI_PROFILE_SPAN_CLOSES=0 HACHI_PROFILE_LOG=info HACHI_PROFILE_ANSI=0.

Metric	Main baseline	Previous run	Latest run	Unit
Setup	3.716	3.768	4.163	s
Commit	1.759	1.770	1.784	s
Prove (Hachi)	4.077	4.045	4.119	s
Prove (Total)	4.077	4.045	4.119	s
Verify (Hachi)	0.177	0.177	0.198	s
Verify (Total)	0.177	0.177	0.198	s
Max RSS	2834.2	2834.2	2832.6	MiB

Proof size: 73,712 B
Hachi fold bytes: 34,288 B
Tail bytes: 39,424 B
Proof framing bytes: 0 B
Hachi levels: 7
Tail shape: 78,848 elems at 4 bits/elem
Observed terminal state: w_len=78,848 with log_basis=4

Per-level parameters

L	Config	D	nA	nB	nD	lb	l1	m	r	δcommit	δopen	δfold	next w (ring)	next w (field)	planned bytes
L0	`D32-na3`	32	3	2	2	2	256	16	11	1	64	11	1,245,760	39,864,320	4,672 B
L1	`D32-na2`	32	2	2	2	2	256	13	8	1	64	10	98,334	3,146,688	4,352 B
L2	`D32-na2`	32	2	2	2	3	256	11	6	1	43	6	17,822	570,304	4,832 B
L3	`D32-na2`	32	2	2	2	4	256	10	5	1	32	5	6,113	195,616	5,216 B
L4	`D32-na2`	32	2	2	2	4	256	9	4	1	32	5	3,707	118,624	5,072 B
L5	`D32-na2`	32	2	2	2	4	256	9	3	1	32	4	2,880	92,160	5,072 B
L6	`D32-na2`	32	2	2	2	4	256	9	3	1	32	4	2,464	78,848	5,072 B

Per-level proof-size breakdown

L	total	y_ring	v	stage1 sc	interstage	s_claim	stage2 sc	next_w_commit	next_w_eval
L0	4,672 B	512	1,024	832	0	16	1,248	1,024	16
L1	4,352 B	512	1,024	704	0	16	1,056	1,024	16
L2	4,832 B	512	1,024	1,280	0	16	960	1,024	16
L3	5,216 B	512	1,024	1,728	32	16	864	1,024	16
L4	5,072 B	512	1,024	1,632	32	16	816	1,024	16
L5	5,072 B	512	1,024	1,632	32	16	816	1,024	16
L6	5,072 B	512	1,024	1,632	32	16	816	1,024	16

4 Polynomials x 30 Variables

Benchmark: 4 same-point 1-of-256 one-hot polynomials with 30 variables each
Batch: same-point opening of 4 polynomials, each with 30 variables.
Sparsity: each polynomial is 1-of-256 one-hot (equivalently, 1-sparse over 256 slots, density 0.39%).
Command: target/release/examples/profile with HACHI_MODE=onehot HACHI_NUM_VARS=30 HACHI_NUM_POLYS=4 HACHI_PROFILE_TRACE=0 HACHI_PROFILE_SPAN_CLOSES=0 HACHI_PROFILE_LOG=info HACHI_PROFILE_ANSI=0.

Metric	Main baseline	Previous run	Latest run	Unit
Setup	5.141	6.359	6.694	s
Commit	2.247	1.997	1.917	s
Prove (Hachi)	3.913	4.038	4.224	s
Prove (Total)	3.914	4.038	4.224	s
Verify (Hachi)	0.178	0.188	0.212	s
Verify (Total)	0.178	0.188	0.212	s
Max RSS	2892.0	3459.5	3459.3	MiB

Proof size: 75,744 B
Hachi fold bytes: 37,024 B
Tail bytes: 38,720 B
Proof framing bytes: 0 B
Hachi levels: 7
Tail shape: 77,440 elems at 4 bits/elem
Observed terminal state: w_len=77,440 with log_basis=4

Per-level proof-size breakdown

L	total	y_ring	v	stage1 sc	interstage	s_claim	stage2 sc	next_w_commit	next_w_eval
L1	4,944 B	512	1,024	1,344	0	16	1,008	1,024	16
L2	4,720 B	512	1,024	1,216	0	16	912	1,024	16
L3	5,216 B	512	1,024	1,728	32	16	864	1,024	16
L4	5,072 B	512	1,024	1,632	32	16	816	1,024	16
L5	5,072 B	512	1,024	1,632	32	16	816	1,024	16
L6	5,072 B	512	1,024	1,632	32	16	816	1,024	16

Posted by Cursor assistant (model: GPT-5.4) on behalf of the user (Quang Dao) with approval.

src/planner/digit_math.rs

src/planner/layout.rs

Remove the private copy in commit.rs and import the canonical pub version from planner::digit_math, preventing silent divergence between the planner and runtime scaling paths. Made-with: Cursor

src/planner/layout.rs

src/protocol/commitment/commit.rs

Keep caller-provided root layouts when sizing batched setup envelopes so custom widths are not replaced by planner defaults. Retain planner-derived batched layouts only when the incoming root matches the config's default singleton layout. Made-with: Cursor

cursor

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Reviewed by Cursor Bugbot for commit 30bf4fc. Configure here.}

cursor · 2026-04-07T23:35:39Z

src/protocol/commitment_scheme.rs

+        let layout = hachi_batched_root_layout::<Cfg, D>(
+            num_vars,
+            setup.expanded.seed.max_num_batched_polys,
+        )?;


Redundant layout computation duplicates plan's internal work

Low Severity

hachi_batched_root_layout::<Cfg, D>(num_vars, max_num_batched_polys) is called directly on line 1998, but hachi_root_runtime_plan_with_batch on line 1992 already calls the same function internally to compute root_plan.root_layout. The old code simply read root_plan.root_layout; the new code recomputes the identical value, duplicating schedule-plan lookups and/or planner work. Using root_plan.root_layout directly avoids the redundant computation.

Additional Locations (1)

src/protocol/commitment_scheme.rs#L1991-L1997

^{Reviewed by Cursor Bugbot for commit 30bf4fc. Configure here.}

omibo added 2 commits April 7, 2026 13:23

cursor bot reviewed Apr 7, 2026

View reviewed changes

src/planner/digit_math.rs Show resolved Hide resolved

Merge remote-tracking branch 'origin/main' into batching/commit

7f9b164

cursor bot reviewed Apr 7, 2026

View reviewed changes

src/planner/layout.rs Outdated Show resolved Hide resolved

refactor: deduplicate compute_num_digits_fold_batched

acc2e16

Remove the private copy in commit.rs and import the canonical pub version from planner::digit_math, preventing silent divergence between the planner and runtime scaling paths. Made-with: Cursor

cursor bot reviewed Apr 7, 2026

View reviewed changes

src/planner/layout.rs Show resolved Hide resolved

src/protocol/commitment/commit.rs Outdated Show resolved Hide resolved

cursor bot reviewed Apr 7, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Batching/commit#45

Batching/commit#45
omibo wants to merge 5 commits intomainfrom
batching/commit

omibo commented Apr 7, 2026

Uh oh!

cursor bot commented Apr 7, 2026 •

edited

Loading

Uh oh!

github-actions bot commented Apr 7, 2026 •

edited

Loading

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

cursor bot left a comment

Uh oh!

cursor bot Apr 7, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

omibo commented Apr 7, 2026

Uh oh!

cursor bot commented Apr 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Summary

Uh oh!

github-actions bot commented Apr 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Benchmark Report

Single Polynomial x 32 Variables

4 Polynomials x 30 Variables

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

cursor bot left a comment

Choose a reason for hiding this comment

Uh oh!

cursor bot Apr 7, 2026

Choose a reason for hiding this comment

Redundant layout computation duplicates plan's internal work

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

cursor bot commented Apr 7, 2026 •

edited

Loading

github-actions bot commented Apr 7, 2026 •

edited

Loading