Skip to content

Conversation

@krsnapaudel
Copy link
Contributor

@krsnapaudel krsnapaudel commented Oct 16, 2025

Description

SSZ support for acct-types and ee-chain-types.

The 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

@github-actions
Copy link
Contributor

github-actions bot commented Oct 16, 2025

Commit: c41fd74

SP1 Execution Results

program cycles success
EVM EE STF 1,324,852
CL STF 330,723
Checkpoint 2,422

@codecov
Copy link

codecov bot commented Oct 16, 2025

Codecov Report

❌ Patch coverage is 73.45133% with 90 lines in your changes missing coverage. Please review.
✅ Project coverage is 74.80%. Comparing base (fd6164d) to head (b447b1b).
⚠️ Report is 3 commits behind head on main.

Files with missing lines Patch % Lines
crates/acct-ssz-types/src/id.rs 17.33% 62 Missing ⚠️
crates/btc-types/src/btc.rs 67.74% 10 Missing ⚠️
crates/acct-types/src/state.rs 86.66% 6 Missing ⚠️
crates/ee-chain-ssz-types/src/block.rs 0.00% 6 Missing ⚠️
crates/acct-ssz-types/src/messages.rs 0.00% 3 Missing ⚠️
crates/acct-ssz-types/src/state.rs 0.00% 3 Missing ⚠️
@@            Coverage Diff             @@
##             main    #1101      +/-   ##
==========================================
+ Coverage   74.62%   74.80%   +0.17%     
==========================================
  Files         510      514       +4     
  Lines       42807    43412     +605     
==========================================
+ Hits        31946    32474     +528     
- Misses      10861    10938      +77     
Flag Coverage Δ
functional 53.68% <0.00%> (+0.21%) ⬆️
unit 54.79% <73.45%> (+0.17%) ⬆️

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

Files with missing lines Coverage Δ
crates/acct-types/src/id.rs 97.95% <100.00%> (+97.95%) ⬆️
crates/acct-types/src/messages.rs 83.33% <100.00%> (+16.66%) ⬆️
crates/ee-chain-types/src/block.rs 100.00% <100.00%> (ø)
crates/acct-ssz-types/src/messages.rs 0.00% <0.00%> (ø)
crates/acct-ssz-types/src/state.rs 0.00% <0.00%> (ø)
crates/acct-types/src/state.rs 64.54% <86.66%> (+64.54%) ⬆️
crates/ee-chain-ssz-types/src/block.rs 0.00% <0.00%> (ø)
crates/btc-types/src/btc.rs 80.34% <67.74%> (-0.12%) ⬇️
crates/acct-ssz-types/src/id.rs 17.33% <17.33%> (ø)

... and 32 files with indirect coverage changes

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

@krsnapaudel krsnapaudel changed the title SSZ 2: acct-types SSZ 2: acct-types and ee-chain-types Oct 16, 2025
@krsnapaudel krsnapaudel force-pushed the ssz-2 branch 2 times, most recently from 5ee7052 to 64813cb Compare October 16, 2025 10:17
Copy link
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.

We want to use pythonic SSZ schemas for all of these. I am not against having a acct-ssz-types crate and then reexporting the generated types from the acct-types crate.

Comment on lines 8 to 15
/// Variable-length list for subject deposits (max 65536 deposits per block)
type SubjectDepositList = VariableList<SubjectDepositData, 65536>;

/// Variable-length list for output transfers (max 65536 transfers per block)
type OutputTransferList = VariableList<OutputTransfer, 65536>;

/// Variable-length list for output messages (max 65536 messages per block)
type OutputMessageList = VariableList<SentMessage, 65536>;
Copy link
Contributor

Choose a reason for hiding this comment

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

These consts should be defined somewhere.

@delbonis delbonis mentioned this pull request Oct 16, 2025
14 tasks
@krsnapaudel
Copy link
Contributor Author

krsnapaudel commented Oct 17, 2025

We want to use pythonic SSZ schemas for all of these. I am not against having a acct-ssz-types crate and then reexporting the generated types from the acct-types crate.

@delbonis : After implementing separate *-ssz-types crates, I hit an issue: due to Rust's orphan rule (can't implement traits on foreign types), I had to move all the implementation (types + business logic + errors) into the *-ssz-types crates, not just SSZ serialization. This creates confusion about where to add new functionality. I am considering consolidating everything back into the original crates (acct-types, ee-chain-types) with pythonic schemas in an ssz/ or ssz-schemas/ subdirectory. The trade-off is that acct-types and ee-chain-types will depend on SSZ libraries. Would this consolidated approach work?

@delbonis
Copy link
Contributor

@krsnapaudel

due to Rust's orphan rule (can't implement traits on foreign types), I had to move all the implementation (types + business logic + errors) into the *-ssz-types crates, not just SSZ serialization. This creates confusion about where to add new functionality.

Yeah that is a little annoying, but a structure like this would work, wouldn't it?

include!(".../whatever/ssz.rs");

impl Foo { // type defined in ssz.ssz, so this impl is able to be defined here
  // ...
}

#[cfg(test)]
mod tests {
  // ...
}

ssz/ or ssz-schemas/ subdirectory

I'm in favor of just ssz/, no need to be unnecessarily verbose.

The trade-off is that acct-types and ee-chain-types will depend on SSZ libraries.

The standard SSZ libraries being included in the dep tree is fine. The proc macros would be a dev-dependency so not actually make it into the actual built binaries.

Would this consolidated approach work?

Part of the motivation suggesting a un-consolidated -ssz-types structure was because sometimes editor tooling gets confused about how to generate the warnings/completions/etc about types generated by macros when in the same crate, but are fine in downstream crates. It also feels better to have the different kinds of definitions separated, so it's clear what kinds of definitions go where. But that's more of vibes-based reason, they're still in separate files, so it shouldn't really matter.

But that being said, these crates are already broken down pretty far, so the above points maybe don't apply strongly. Not sure how I feel about it.

@krsnapaudel
Copy link
Contributor Author

krsnapaudel commented Oct 22, 2025

@delbonis I have used include! from a separate crate. Other than the relative path for include!, this looks fine. For BitcoinAmount, we don't have a separate ssz schema, although it does appear in acct-types.ssz. It comes from btc-types. The SSZ support is directly added to it.

@krsnapaudel krsnapaudel marked this pull request as ready for review October 22, 2025 11:51
Copy link
Member

@storopoli storopoli left a comment

Choose a reason for hiding this comment

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

Comment on lines +105 to +124
fn ssz_fixed_len() -> usize {
2
}

fn ssz_bytes_len(&self) -> usize {
2
}

fn ssz_append(&self, buf: &mut Vec<u8>) {
(*self as u16).ssz_append(buf);
}
}

impl ssz::Decode for AccountTypeId {
fn is_ssz_fixed_len() -> bool {
true
}

fn ssz_fixed_len() -> usize {
2
Copy link
Member

Choose a reason for hiding this comment

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

Can we move all these 2 into a const with proper docstrings?

Comment on lines +248 to +249
ssz_derive::Encode,
ssz_derive::Decode,
Copy link
Member

Choose a reason for hiding this comment

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

Can we import these Encode/Decode in the top of the file with use?

fn test_bitcoin_amount_tree_hash() {
use tree_hash::TreeHash;

let amount = BitcoinAmount::from_sat(1000);
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
let amount = BitcoinAmount::from_sat(1000);
let amount = BitcoinAmount::from_sat(1_000);

Comment on lines +1528 to +1535
fn test_bitcoin_amount_ssz_roundtrip() {
use ssz::{Decode, Encode};

let amount = BitcoinAmount::from_sat(12345);
let encoded = amount.as_ssz_bytes();
let decoded = BitcoinAmount::from_ssz_bytes(&encoded).unwrap();
assert_eq!(amount, decoded);
}
Copy link
Member

Choose a reason for hiding this comment

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

This could be a property test proptest!. See https://github.com/alpenlabs/bitcoin-bosd/blob/21c257df5c45cac22b91b0c5b1ed78b9fd3dc25f/src/serde.rs#L62-L85

Check the intro in https://proptest-rs.github.io/proptest/intro.html
for a quick introduction on what are property tests if you want.

Comment on lines +52 to +57
fn test_account_id_ssz_roundtrip() {
let id = AccountId([42u8; 32]);
let encoded = id.as_ssz_bytes();
let decoded = AccountId::from_ssz_bytes(&encoded).unwrap();
assert_eq!(id, decoded);
}
Copy link
Member

Choose a reason for hiding this comment

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

proptest! as well

}

#[test]
fn test_subject_deposit_data_ssz_roundtrip() {
Copy link
Member

Choose a reason for hiding this comment

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

another roundtrip test the can be done with proptest!

}

#[test]
fn test_block_inputs_ssz_roundtrip_with_deposits() {
Copy link
Member

Choose a reason for hiding this comment

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

another roundtrip test the can be done with proptest!

}

#[test]
fn test_output_transfer_ssz_roundtrip() {
Copy link
Member

Choose a reason for hiding this comment

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

another roundtrip test the can be done with proptest!

}

#[test]
fn test_block_outputs_ssz_roundtrip_with_data() {
Copy link
Member

Choose a reason for hiding this comment

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

another roundtrip test the can be done with proptest!

}

#[test]
fn test_exec_block_notpackage_ssz_roundtrip() {
Copy link
Member

Choose a reason for hiding this comment

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

another roundtrip test the can be done with proptest!

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