Bundle Compression

Date

January 1, 2024

Author

DC Posch

Contract accounts aren’t just better, they’re also cheaper.

Background…

The future of Ethereum is contract accounts on rollups.

Together, contract accounts (also known as “account abstraction”) and rollups represent a fundamental upgrade & enable real-world use of the chain:

• Fast, cheap transactions.
• Secure accounts built on best-practice cryptography.
• Better recovery, including easy-to-use passkey backups. No seed phrase.

EOAs and L1 are settlement infrastructure. The future is 4337 on L2. The problem, so far, was that 4337 on L2 was expensive.

Making 4337-on-L2 efficient

The main cost on L2 is calldata. 4337 can use a lot of that. For example, see Ansgar’s breakdown of what Vitalik later called the “infamous 1600-byte transfer”: a 4337 bundle containing a single Daimo USDC transfer.

We fix this using bundle compression.

The BundleBulker contract is simple and permissionless. Any bundler can register their own IInflator to compress bundles however they want. A good default is the PerOpInflator, which concatenates individually compressed ops. Each bundler (Pimlico, ThirdWeb, Alchemy, etc) can deploy their own PerOpInflator instance, with the beneficiary (op fee recipient) set accordingly. PerOpInflator is similarly permissionless: any app can register their own IOpInflator with arbitrary, app-specific userop compression.

For an example, check out DaimoOpInflator. What it is doing, specifically?

• Packing. The Solidity ABI encoding was designed for L1, where computation is expensive, not for L2, where computation is effectively free and calldata is expensive. A single boolean argument takes 32 bytes… structs are encoded in a luxuriously expansive way.
• Templating. Parts of the op that don’t change are templated in. In our case, callGasLimit, verificationGasLimit, and the WebAuthn (passkey) JSON envelope.
• Stateful compression. We replace the 40 byte (from address, to address) with a ~10 byte (from name, to name) using our existing onchain name registry. We could further optimize by using an index instead of a name.

The important thing is that this setup is permissionless. Any app can write their own inflator and start using it.

Results

Results so far, using a simple ERC20 token transfer as our benchmark.

Below: a 4337 bundle containing a single USDC transfer, before and after compression. In both cases, I’ve highlighted the op. The rest is the bundle fixed overhead.

The highlighted op is smaller than an EOA ERC-20 transfer.

Each bundle will contain many of these, amortizing the fixed overhead & making contract wallets more efficient than legacy wallets.

Questions

• What about rollup compression?

Bundle compression is complementary to rollup compression. Both are useful.

Rollups compress calldata before settling to L1, but this is limited on its own. Stateful compression is hard to achieve. Bundle compression is at the app layer and lets you do application-specific templating and stateful lookups.

Together, this lets us approach the goal state of very compact transactions.

• Why use 4337 at all, if we’re calling into another contract that sits in front of the EntryPoint?

Three reasons.

1. Standard ops. Userop explorer, ops identified by ophash, everything inter-”op”-erable. If you use bespoke AA, you get no observability or devtools. Note that a userop explorer will show the uncompressed op, —it’ll just have a lower preVerificationGas = lower cost.
2. Censorship resistance. Bundler down or not serving you? Your wallet can send the uncompressed op to the standard 4337 mempool, paying a few cents more fee for guaranteed inclusion.
3. Security. Stick with the battle-tested EntryPoint contract. See below.
• What if there’s a vulnerability in my inflator?

The inflator contract is, unavoidably, not beautiful to look at. You’re writing a byte-packed encoding, plus templating and lookups.

The great news is that the inflator contract has no security responsibilities. This is because your wallet still signs over the uncompressed op. The EntryPoint contract and your 4337 wallet’s validateUserOp function work exactly as before. If there’s any issue in the inflator contract, it can only cause liveness problems (reverted, invalid ops), not security errors. It’s neatly compartmentalized as an optional optimization.

In fact, this separation of responsibilities makes your wallet more secure. The gross bit-packing goes in one place—the security-critical validation logic goes in another, which can written in entirely idiomatic Solidity.

• Doesn’t state diff fix this?

State diffs are an elegant theoretical optimization for zkrollups: just prove that you have a block of valid transactions resulting in a given diff. The transactions themselves, and their calldata, are not posted! For a transfer, the diff is just (-10 for alice, +10 for bob). No compression needed.

We’re unlikely to see this in a production, real, stage2 rollup. A state-diff-only permissionless rollup is a scary construct. It raises the spectre of undiagnosable hacks, both of the rollup itself and applications on top. Say a block shows up that drains a defi protocol. You might never learn what the bug was! The transaction was never published, only the final state diff (minus $500m for contract 0x…, plus $500m for bob) and a proof that some valid set of transactions produced this diff. Similarly for proving-system bugs.

TLDR; production rollups will post calldata for the forseeable future.

• How do I add this?

Instructions coming once we have bundler support. In the meantime, our production implementation is open source.

Next steps