Skip to content

Conversation

@roynalnaruto
Copy link
Contributor

@roynalnaruto roynalnaruto commented Jun 10, 2025

Fixes #42.

The PR implements the proposed updates to rollup-fee for ScrollSpecId::FEYNMAN.

rollup_fee(tx) = compression_factor(tx) * size(rlp(tx)) * (
	exec_scalar * l1_base_fee + 
	blob_scalar * l1_blob_base_fee
)

# compression_factor = 1.0 / compression_ratio
0.0 < compression_factor(tx) <= 1.0
exec_scalar = compression_scalar + commit_scalar + verification_scalar
blob_scalar = compression_scalar + blob_scalar

Assumption

compression_factor = 1 until further notice

@roynalnaruto roynalnaruto requested a review from Thegaram June 11, 2025 08:59
Copy link
Contributor

@Thegaram Thegaram left a comment

Choose a reason for hiding this comment

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

lgtm, would be nice to add some tests

@roynalnaruto roynalnaruto requested a review from Thegaram June 11, 2025 14:18
Thegaram
Thegaram previously approved these changes Jun 11, 2025
Copy link
Collaborator

@frisitano frisitano left a comment

Choose a reason for hiding this comment

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

Looks good, thanks for adding the documentation, that's super insightful and helpful. I added a question inline around the compression_ratio.

src/l1block.rs Outdated
//
// We use the `TX_L1_FEE_PRECISION` to allow fractions. We then divide the overall product
// by the precision value as well.
let compression_ratio = |_input: &[u8]| -> U256 { TX_L1_FEE_PRECISION };
Copy link
Collaborator

Choose a reason for hiding this comment

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

From my understanding, we will assume the worst case in the prover, i.e. the compression ratio is 1. Is this the case, or will the prover also estimate compression? If the prover logic and execution node logic is different, how will we capture that here? Do we need to feature flag this here, depending on whether we are running as a prover or not?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The prover should not need to estimate compression ratio, specifically because zstd-encoding will add a lot of cycles to our batch prover (which we would like to avoid).

You are probably right, we will eventually need feature flag to either:

  1. prover: fix upper bound for rollup fee (assuming compression ratio == 1)
  2. node: calculating the actual rollup fee by estimating the compression_ratio with zstd-encoding

And we additionally must then constrain the rollup fee to be at the most the upper bound (in the prover).

Let's keep this PR unmerged until we resolve this conversation.

@frisitano
Copy link
Collaborator

I have some thoughts on how we can address the compression factor for the prover. We introduce a compression_factor: Option< U256 > field in the ScrollTransaction:

/// A Scroll transaction. Wraps around a base transaction and provides the optional RLPed bytes for
/// the l1 fee computation.
#[derive(Clone, Debug, PartialEq, Eq)]
#[cfg_attr(feature = "serde", derive(serde::Serialize, serde::Deserialize))]
pub struct ScrollTransaction<T: Transaction> {
pub base: T,
pub rlp_bytes: Option<Bytes>,
}

We provide a utility to compute the compression factors for all transactions in the host. These compression factors should be computed by the utility and then added to the witness. The witness is then provided to the guest. Inside the guest, we modify the EVM to enable access to the compression factor for each transaction. Inside of the rollup_fee function, we assert the compression factor is less than one and use it to compute the rollup_fee.

@roynalnaruto @Thegaram, I'm keen to hear your feedback on this approach.

@Thegaram
Copy link
Contributor

Superseded by #50.

@Thegaram Thegaram closed this Jun 25, 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.

Implement Feynman rollup fee formula

4 participants