Skip to content

Conversation

@krsnapaudel
Copy link
Contributor

@krsnapaudel krsnapaudel commented Oct 15, 2025

Description

SSZ support for checkpoint types per SPS-62.

This PR was created with help from Claude Code.

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

Notes to Reviewers

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

@krsnapaudel krsnapaudel requested review from a team as code owners October 15, 2025 11:04
@krsnapaudel krsnapaudel marked this pull request as draft October 15, 2025 11:04
@krsnapaudel krsnapaudel self-assigned this Oct 15, 2025
@codecov
Copy link

codecov bot commented Oct 15, 2025

Codecov Report

❌ Patch coverage is 94.87179% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 74.70%. Comparing base (1dc83bc) to head (90225d4).

Files with missing lines Patch % Lines
crates/sps62-checkpoint-types/src/types.rs 94.87% 6 Missing ⚠️
@@           Coverage Diff            @@
##             main    #1098    +/-   ##
========================================
  Coverage   74.69%   74.70%            
========================================
  Files         511      512     +1     
  Lines       42825    42942   +117     
========================================
+ Hits        31988    32079    +91     
- Misses      10837    10863    +26     
Flag Coverage Δ
functional 53.32% <ø> (-0.04%) ⬇️
unit 54.78% <94.87%> (+0.08%) ⬆️

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

Files with missing lines Coverage Δ
crates/sps62-checkpoint-types/src/types.rs 94.87% <94.87%> (ø)

... and 7 files with indirect coverage changes

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

@github-actions
Copy link
Contributor

github-actions bot commented Oct 15, 2025

Commit: 030301e

SP1 Execution Results

program cycles success
EVM EE STF 1,172,528
CL STF 330,723
Checkpoint 2,422

Copy link
Contributor

Choose a reason for hiding this comment

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

Should we be converting over to using types that look like this and then convert to SSZ or vice versa? Converting over the existing types I think is kinda a wasted effort since we know we'll be changing them.

Copy link
Contributor Author

@krsnapaudel krsnapaudel Oct 16, 2025

Choose a reason for hiding this comment

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

I updated the PR to add SSZ to SPS-62 checkpoint types. According to @prajwolrg, the work on SPS-62 types is not done yet. I will create other PRs for types that already exist.

Comment on lines 19 to 29
impl From<borsh::L1BlockCommitment> for crate::L1BlockCommitment {
fn from(value: borsh::L1BlockCommitment) -> Self {
Self {
height: value.height_u64(),
blkid: FixedVector::from(value.blkid().as_ref().to_vec()),
}
}
}

impl From<crate::L1BlockCommitment> for borsh::L1BlockCommitment {
Copy link
Contributor

Choose a reason for hiding this comment

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

Only use crate:: imports in use decls.

Copy link
Contributor

Choose a reason for hiding this comment

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

What is the rationale for introducing new crates just for the SSZ serialization?

My thought was that instead of making new crates for the SSZ definitions, we should convert the existing crates over to using the SSZ definitions, removing the borshy ones (which we want to eliminate anyways) and manually adding the extra conversion impls where needed. This way we won't need an additional conversion step before serialization / after deserialization that does what is essentially an extra copy.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I did have an exchange with Claude Code about this. I felt the conversion was not necessary. The original rationale was to avoid introducing breaking changes and allow gradual migration. I agree with your suggestion. So will update the PR soon.

@krsnapaudel krsnapaudel force-pushed the ssz-1 branch 4 times, most recently from 1cb9b49 to c33b6f7 Compare October 16, 2025 07:21
@krsnapaudel krsnapaudel changed the title SSZ 1: identifiers and checkpoint-types SSZ 1: SPS-62 checkpoint-types Oct 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants