Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fault_proving(compression_service): initial scaffold for dedicated compression service #2788

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

rymnc
Copy link
Member

@rymnc rymnc commented Mar 3, 2025

Linked Issues/PRs

Description

Given that we want to modularize the compression service from the offchain worker, this PR begins the refactor.

Things to keep in mind while reviewing -

  • ports/errors/config/storage traits will evolve with this integration
  • we will remove temporary compiler/clippy rules once integration is done
  • tests will come as well
  • codeowners file has new entry for this service to help expedite reviews

This pull request introduces a new dedicated compression service for fuel blocks. The key changes include scaffolding the service, defining its configuration, errors, and ports, and implementing the service logic. Below are the most important changes:

New Service Implementation:

  • Scaffold Compression Service: Added a new compression service responsible for compressing fuel blocks for Data Availability (DA). (.changes/added/2788.md)
  • Service Definition: Implemented the CompressionService struct and its associated methods to handle new blocks, perform compression, and manage service state. (crates/services/compression/src/service.rs)

Configuration and Dependencies:

  • Cargo.toml Updates: Added the new compression service to the workspace and defined its dependencies. (Cargo.toml, crates/services/compression/Cargo.toml) [1] [2]
  • Configuration: Defined the CompressionConfig struct for service configuration. (crates/services/compression/src/config.rs)

Error Handling:

  • Error Definitions: Created the CompressionError enum to handle various errors that may occur during the compression process. (crates/services/compression/src/errors.rs)

Ports and Interfaces:

  • Ports for Service Interaction: Defined ports for block source, compression storage, and configuration to interact with the service. (crates/services/compression/src/ports.rs, crates/services/compression/src/ports/block_source.rs, crates/services/compression/src/ports/compression_storage.rs, crates/services/compression/src/ports/configuration.rs) [1] [2] [3] [4]

Code Ownership:

  • CODEOWNERS Update: Assigned the new compression service to the appropriate code owners. (.github/CODEOWNERS)

Checklist

  • Breaking changes are clearly marked as such in the PR description and changelog
  • New behavior is reflected in tests
  • The specification matches the implemented behavior (link update PR if changes are needed)

Before requesting review

  • I have reviewed the code myself
  • I have created follow-up issues caused by this PR and linked them here

After merging, notify other teams

[Add or remove entries as needed]

@rymnc rymnc self-assigned this Mar 3, 2025
@rymnc rymnc force-pushed the chore/dedicated-compression-service branch 5 times, most recently from 035c97c to c82613f Compare March 3, 2025 14:41
@rymnc rymnc marked this pull request as ready for review March 3, 2025 14:54
@rymnc rymnc requested review from a team, xgreenx, Dentosal and MitchTurner as code owners March 3, 2025 14:54
xgreenx
xgreenx previously approved these changes Mar 3, 2025
netrome
netrome previously approved these changes Mar 3, 2025
Copy link
Contributor

@netrome netrome left a comment

Choose a reason for hiding this comment

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

Nice stuff. Just some nits and suggestions but nothing major from me.

@@ -0,0 +1,21 @@
use thiserror::Error;
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: I believe thiserror doesn't work with no-std. Don't think we need it for now, but if we were to pivot to run compression in a zkvm in the future it's a bit more convenient if we derive derive_more::Error instead.

Copy link
Member Author

Choose a reason for hiding this comment

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

we will never mount the service inside a zkvm. there's no need to make this no-std compatible yet

Comment on lines +4 to +21
#[derive(Error, Debug)]
pub enum CompressionError {
// L2 block source Errors
/// Failed to get l2 block
#[error("failed to get l2 block: `{0}`")]
FailedToGetBlock(String),
// Compression storage Errors
/// Failed to read compressed block from storage
#[error("failed to write compressed block to storage: `{0}`")]
FailedToWriteCompressedBlock(String),
// Service errors
/// Failed to create service
#[error("failed to create service: `{0}`")]
FailedToCreateService(String),
/// Failed to handle new block
#[error("failed to handle new block: `{0}`")]
FailedToHandleNewBlock(String),
}
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't see these used anywhere. Are the inner Strings just placeholders for later dedicated types? Nit: I'd default to &'static str instead of String.

Copy link
Member Author

Choose a reason for hiding this comment

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

placeholder for now.

Copy link
Member Author

Choose a reason for hiding this comment

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

even the String's are just placeholders till we get some concrete types in :)

Comment on lines +2 to +11
pub type Block = fuel_core_types::blockchain::block::Block;

/// Port for L2 blocks source
/// Each time `.next()` is called, the service expects the same behaviour as an iterator.
pub trait BlockSource {
/// Get the next block from the source
fn next(
&self,
) -> impl core::future::Future<Output = crate::Result<Option<Block>>> + Send + Sync;
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: I'd rename the method to next_block for clarity. But I think next probably also works if the variable in the calling code is properly named.

Suggested change
pub type Block = fuel_core_types::blockchain::block::Block;
/// Port for L2 blocks source
/// Each time `.next()` is called, the service expects the same behaviour as an iterator.
pub trait BlockSource {
/// Get the next block from the source
fn next(
&self,
) -> impl core::future::Future<Output = crate::Result<Option<Block>>> + Send + Sync;
}
pub type Block = fuel_core_types::blockchain::block::Block;
/// Port for L2 blocks source
/// Each time `.next()` is called, the service expects the same behaviour as an iterator.
pub trait BlockSource {
/// Get the next block from the source
fn next_block(
&self,
) -> impl core::future::Future<Output = crate::Result<Option<Block>>> + Send + Sync;
}

Copy link
Member Author

Choose a reason for hiding this comment

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

block_source.next() makes more sense to me than block_source.next_block(). also given that we allude to an iterator format here I think it is reasonable to assume the stream is of blocks.

@rymnc rymnc dismissed stale reviews from netrome and xgreenx via 9336bd0 March 4, 2025 00:37
@rymnc rymnc force-pushed the chore/dedicated-compression-service branch from c82613f to 9336bd0 Compare March 4, 2025 00:37
@rymnc rymnc requested review from xgreenx and netrome March 4, 2025 00:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants