Skip to content

draft: measure SP1 checkpoint capacity for 2048 manifests#1930

Draft
krsnapaudel wants to merge 1 commit into
mainfrom
STR-2750
Draft

draft: measure SP1 checkpoint capacity for 2048 manifests#1930
krsnapaudel wants to merge 1 commit into
mainfrom
STR-2750

Conversation

@krsnapaudel
Copy link
Copy Markdown
Contributor

@krsnapaudel krsnapaudel commented Jun 2, 2026

Description

Measurement-only PR. Do not merge.

This PR triggers a branch-gated SP1 network proof job for
CHECKPOINT_CAPACITY_MANIFEST_COUNTS=2048, repeated 3 times, to evaluate whether
MAX_SEALING_MANIFEST_COUNT=2048 has acceptable proof stability/runtime.

Also exercises max checkpoint log limit. For deposit log limit, it seems pending ASM logs limit kicks in limiting deposit logs per ASM manifest to 32.

Type of Change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature/Enhancement (non-breaking change which adds functionality or enhances an existing one)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Documentation update
  • Refactor
  • New or updated tests
  • Dependency Update
  • Experitment

Notes to Reviewers

Is this PR addressing any specification, design doc or external reference document?

  • Yes
  • No

If yes, please add relevant links:

Checklist

  • I have performed a self-review of my code.
  • I have commented my code where necessary.
  • I have updated the documentation if needed.
  • My changes do not introduce new warnings.
  • I have added (where necessary) tests that prove my changes are effective or that my feature works.
  • New and existing tests pass with my changes.
  • I have disclosed my use of AI in the body of this PR.

Related Issues

STR-2750

@krsnapaudel krsnapaudel self-assigned this Jun 2, 2026
@krsnapaudel krsnapaudel added the DO NOT MERGE This PR should not be merged as long as this tag is present. label Jun 2, 2026
@krsnapaudel krsnapaudel marked this pull request as draft June 2, 2026 18:53
Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 78d324e4af

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

Comment thread crates/proof-impl/checkpoint/src/program.rs
@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented Jun 2, 2026

Commit: de83875

SP1 Execution Results

program cycles gas
EVM EE Chunk 824,732 969,395
EVM EE Account 404,056 498,593
Checkpoint-256 115,323,166 127,714,821
Checkpoint-256 115,323,166 127,714,821
Checkpoint-512 184,855,655 204,569,410
Checkpoint-1024 324,404,390 358,432,206
Checkpoint-2048 603,032,345 666,111,945

@codecov
Copy link
Copy Markdown

codecov Bot commented Jun 2, 2026

Codecov Report

❌ Patch coverage is 28.12500% with 368 lines in your changes missing coverage. Please review.
✅ Project coverage is 84.12%. Comparing base (1556d34) to head (d982eb2).
⚠️ Report is 2 commits behind head on main.

Files with missing lines Patch % Lines
crates/proof-impl/checkpoint/src/program.rs 0.00% 189 Missing ⚠️
bin/prover-perf/src/programs/checkpoint.rs 56.25% 112 Missing ⚠️
bin/prover-perf/src/format.rs 0.00% 31 Missing ⚠️
bin/prover-perf/src/main.rs 0.00% 21 Missing ⚠️
bin/prover-perf/src/programs/mod.rs 0.00% 15 Missing ⚠️
@@            Coverage Diff             @@
##             main    #1930      +/-   ##
==========================================
- Coverage   84.47%   84.12%   -0.35%     
==========================================
  Files         645      645              
  Lines       77591    78051     +460     
==========================================
+ Hits        65543    65659     +116     
- Misses      12048    12392     +344     
Flag Coverage Δ
functional 66.57% <ø> (+0.14%) ⬆️
unit 69.37% <28.12%> (-0.29%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines Coverage Δ
bin/prover-perf/src/args.rs 0.00% <ø> (ø)
bin/prover-perf/src/programs/mod.rs 0.00% <0.00%> (ø)
bin/prover-perf/src/main.rs 0.00% <0.00%> (ø)
bin/prover-perf/src/format.rs 0.00% <0.00%> (ø)
bin/prover-perf/src/programs/checkpoint.rs 57.08% <56.25%> (-28.02%) ⬇️
crates/proof-impl/checkpoint/src/program.rs 37.86% <0.00%> (-59.64%) ⬇️

... and 9 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Copy link
Copy Markdown
Contributor

@delbonis delbonis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Parts of how this works / is configured are not very self-explanatory and should have things renamed.

Comment on lines +37 to +42
class NoServicesEnv(flexitest.EnvConfig):
"""Functional-test env with no long-running services."""

def init(self, ectx: flexitest.EnvContext) -> flexitest.LiveEnv:
return flexitest.LiveEnv({})

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Technically this type should be called something like NoServicesEnvConfig, or really EmptyEnvConfig is more idiomatic. It's not an env itself it's the env conifg.

Comment on lines +35 to +36
const CAPACITY_MANIFEST_COUNTS_ENV: &str = "CHECKPOINT_CAPACITY_MANIFEST_COUNTS";
const CAPACITY_OL_LOG_TARGET_ENV: &str = "CHECKPOINT_CAPACITY_OL_LOG_TARGET";
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This envvar naming is very confusing, I have no idea what they are supposed to represent. Should these maybe be

  • CHECKPOINT_MANIFEST_CAPACITY_something
  • CHECKPOINT_TARGET_OL_LOG_CAPACITY

?

Comment on lines +38 to +71
fn candidate_manifest_counts() -> Vec<usize> {
if let Ok(raw_counts) = env::var(CAPACITY_MANIFEST_COUNTS_ENV) {
let mut counts: Vec<usize> = raw_counts
.split(',')
.map(str::trim)
.filter(|count| !count.is_empty())
.map(|count| {
count.parse::<usize>().unwrap_or_else(|e| {
panic!("{CAPACITY_MANIFEST_COUNTS_ENV} contains invalid count {count:?}: {e}")
})
})
.collect();
assert!(
!counts.is_empty(),
"{CAPACITY_MANIFEST_COUNTS_ENV} must include at least one count"
);
counts.retain(|count| *count <= MAX_SEALING_MANIFEST_COUNT as usize);
assert!(
!counts.is_empty(),
"{CAPACITY_MANIFEST_COUNTS_ENV} contains no count <= MAX_SEALING_MANIFEST_COUNT"
);
counts.sort_unstable();
counts.dedup();
return counts;
}

// First block is the parent (genesis); remaining blocks are the proving batch.
let parent = blocks.remove(0).into_header();
let mut candidates = vec![256, 512, 1024, MAX_SEALING_MANIFEST_COUNT as usize];
candidates.retain(|count| *count <= MAX_SEALING_MANIFEST_COUNT as usize);
candidates.sort_unstable();
candidates.dedup();
candidates
}

// Rebuild start_state: execute just the genesis block to get state after genesis.
let mut start_state = make_genesis_state();
let _ = build_empty_chain(&mut start_state, 1, SLOTS_PER_EPOCH)
.expect("build_empty_chain should succeed");
fn capacity_ol_log_target() -> Option<usize> {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similarly, these fn names are really hard to understand.

.collect()
}

fn checkpoint_report_name(manifest_count: usize, ol_log_target: Option<usize>) -> String {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

get_?

Comment on lines +169 to +175
fn buf32_from_l1_height(height: L1Height, domain: u8) -> Buf32 {
let mut bytes = [domain; 32];
let height_bytes = height.to_le_bytes();
bytes[..height_bytes.len()].copy_from_slice(&height_bytes);
Buf32::from(bytes)
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see a fn like this in checkpoint.rs. Does it make sense to consolidate these so there's a single consistent impl?

Comment on lines +217 to +220
fn prepare_input_with_terminal_manifests_and_ol_log_target(
manifest_count: usize,
ol_log_target: Option<usize>,
) -> CheckpointProverInput {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Surely parts of this fn could be broken apart into more reusable components.

@krsnapaudel
Copy link
Copy Markdown
Contributor Author

Parts of how this works / is configured are not very self-explanatory and should have things renamed.

@delbonis This is not meant to be merged. Just experimenting to see manifest count of 2048 runs into any issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

DO NOT MERGE This PR should not be merged as long as this tag is present.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants