feat: add compute_compressed_size for Galileo

[Thegaram]

This PR bumps revm to include the updated Galileo rollup fee (scroll-tech/scroll-revm#65), and adds logic to compute compressed_size(rlp(tx)) used in the formula.

The main changes are:

• In crates/scroll/alloy/evm/src/tx/compression.rs, introduce the function compute_compressed_size in addition to the existing compute_compression_ratio. These both use zstd.
• Functions taking a compression_ratio argument now take an additional compressed_size argument.
• Related traits (WithCompressionRatio, FromTxWithCompressionRatio) are renamed to *CompressionInfo.

Important notes:

• In Feynman, compression_ratio is computed on the transaction payload only. On the other hand, Galileo's compressed_size is computed on the full rlp-encoded transaction.
• Because of the previous point, we cannot combine the two compression operations, and so we run zstd 2x for each transaction. I opened an issue for a optimizing this in the future.

[codspeed-hq]

CodSpeed Performance Report

Merging #355 will not alter performance

_{Comparing feat-galileo-rollup-fee (7150467) with scroll (414c692)}

Summary

✅ 77 untouched

[roynalnaruto]

Correctness wise I don't really see an issue.

I just want to mention however that based on the current approach, we call compute_compression_ratio and compute_compressed_size for each transaction. Do note that compute_compression_ratio itself also calls compute_compressed_size to compute the ratio.

Effectively, compute_compressed_size is being called twice per transaction, meaning that the zstd-encoding is being performed twice per transaction. As such this is not desirable.

Since the inputs to both calls are different -- tx.input vs rlp-encoded tx, I suppose this is unavoidable, right?

[Thegaram]

Since the inputs to both calls are different -- tx.input vs rlp-encoded tx, I suppose this is unavoidable, right?

Yes, that was my conclusion.

Though in practice, we only need compression_ratio for Feynman, and we only need compressed_size for Galileo, i.e. we never need both.

There are some code paths where deciding which fork is active for a transaction is not straightforward (txpool, rpc), so after discussion with @frisitano, I suggest that we merge the current version and keep this as a future optimization. This "double compression" has no impact on proving performance, and can be optimized in reth later without a hard fork.