Content
@
0 reply
0 recast
0 reaction
Oren Yomtov
@orenyomtov
Will this approach really reduce ERC-4337 UserOp fees by ~35% to all /op-stack (e.g. /base) users, or am I missing something? @dcposch.eth
3 replies
0 recast
3 reactions
abstractooor
@konrad
how did you calculate arbitrum calldata compression? and is this code open source?
1 reply
0 recast
1 reaction
Oren Yomtov
@orenyomtov
My PR is here: https://github.com/daimo-eth/bulk/pull/8 Arbitrum docs explain calldata compression used in gas estimation: https://docs.arbitrum.io/devs-how-tos/how-to-estimate-gas Arbitrum code: https://github.com/OffchainLabs/nitro/blob/27d9d4482c4ada93d4da597373eb41be962348a7/arbos/l1pricing/l1pricing.go#L503
1 reply
0 recast
2 reactions
abstractooor
@konrad
cool thanks - so this is using zlib for arbitrum (through pako) instead of brotli right?
2 replies
0 recast
0 reaction
Oren Yomtov
@orenyomtov
And just to clarify - Arbirtum is using brotli when calculating the L1 data cost of an L2 transaction. In comparison, OP-Stack chains just multiply their L2 calldata by 0.684. That's why I think we can gain a "double compression discount" on OP-Stack chains. It also raises alignment/incentive structure questions...
1 reply
0 recast
1 reaction
abstractooor
@konrad
My point was more that zlib != brotli so was wondering if you knew roughly how they compare in terms of compression output
1 reply
0 recast
0 reaction
Oren Yomtov
@orenyomtov
Ohh that wasn't my angle on it. I saw they benchmarked a bunch of compression algorithms before choosing brotli, and assumed compressing compressed data will yield negligible savings (maybe even offset by execution gas costs of decompression) so I didn't research that angle
1 reply
0 recast
1 reaction
abstractooor
@konrad
ah ok makes sense - I've also been using a different but similar algorithm (fastzl) but havent gotten around to test the differences yet (in my case this is bc I'm doing the compression in solidity and didnt wanna write a solidity impl of brotli)
0 reply
0 recast
0 reaction
